Re: Request: Support for __JOIN(c1.fkey c2)__

[prev] [thread] [next] [Date index for 2005/05/05]

On Thu, May 05, 2005 at 10:31:08AM -0500, Stepan Riha wrote:
> Are you talking about the syntax in the perl code or the syntax in the 
> __JOIN__?

The JOIN.

>  I'd love to expand the documentation on the __JOIN__, but AFAIK there ain't
> none, right?

Yet. :)

It's one of those things I didn't like to document in case it turned out
to be a blind alley. But I've used it in a lot of production code now,
and it turns out to work quite well, so I guess it's ready for promotion
to properly documented status.

> Film->set_sql(directors_born_before => <<'');
>    SELECT __ESSENTIAL(f)__
>    FROM __TABLE(Film f)__, __TABLE(Director d)__
>    WHERE __JOIN(f.Director d)__ AND d.Birthday <= ?
> 
> Film->set_sql(codirectors_born_before => <<'');
>    SELECT __ESSENTIAL(f)__
>    FROM __TABLE(Film f)__, __TABLE(Director d)__
>    WHERE __JOIN(f.CoDirector d)__ AND d.Birthday <= ?

OK. I get it now. 

I'm not /entirely/ convinced by the syntax, but I'm 95% there. I'll give
it a little more thought, but it's probably OK.

> As far as testing goes, you could add the following to 19-set_sql.t:

Will do. Thanks.

> BTW, I think that transform_sql should test for and complain if it's 
> expanding a has_a relationship that's ambiguous (i.e. "__JOIN(f d)__" in 
> my example).  My code doesn't do that check.

That sounds like a good idea too.

> Also, a similar problem exists when specifying has_many relationships:
>     Director->has_many( DirectedFilms => 'Film');
>     Director->has_many( CoDirectedFilms => 'Film');
> Again, when ambiguous, you should be able to specify the foreign key and 
> CDBI should croak on ambiguities:

You already can specify the foreign key - it's the 3rd argument to
has_many.

However, it probably should croak on ambiguity.

> Anyway, I'm using the new __JOIN__ syntax in an enhanced AbstractSearch 

Looks good.

Thanks for the work here.

Tony