Outer joins: CAY-929

[Andrus Adamchik <an...@objectstyle.org>]

This is regarding Mike Kienenberger's comment from December 3 on  
CAY-929:

"This is really a duplicate of CAY-560. There's selectTranslator  
support in there already for left (outer) joins. It's just a matter of  
eventually merging that code into 3.0 and, like you said, deciding how  
it fits into the grand plan of EJBQL."


Mike,

CAY-560 was sitting in the queue for a while, maybe cause it is too  
loaded... I was reviewing our options recently (now that EJBQL  
translator is in place), and figured it probably won't make sense (to  
convert SelectQuery to an EJBQL query internally on the short run  
anyways ... maybe we'll do it in 3.1 or something) . It would look  
approximately like this:

SelectQuery -> EJBQLQuery -> SQLTemplate -> SQL

The chain is too long.... So while EJBQLQuery is a good choice if you  
need expressions with outer joins, SelectTranslator will still benefit  
from outer join support in a number of cases that Ari described in  
Jira, where Cayenne can make an implicit decision about join semantics.

Anton Sakalouski of ObjectStyle (you may remember him - he developed a  
PDF docs generator for Cayenne many years ago, although he hasn't been  
active in the community) was looking to implement a patch for  
SelectTranslator per CAY-929. So if you decide to go ahead with  
CAY-560, you'll have fewer things to port ;-)

Andrus

Re: Outer joins: CAY-929

[Mike Kienenberger <mk...@gmail.com>]

I don't have a problem with someone else doing it, but there are some
consequences.

I've been extremely sick for four weeks now, and selectively reading
some of my email is about the limit of my abilities.

Adding selectTranslator support for outer joins was very complicated
as table aliases now become context-sensitive to the query qualifier.
 And much of the outer join support hinged on it.    I'd recommend
porting the CAY-560 patch into 3.0 rather than trying to reinvent this
wheel.    If the code isn't ported in, then the rest of CAY-560 will
also likely have to be redone from scratch.

The only thing the CAY-560 patch is lacking is "real" parser support.
 If I recall, it was beyond my ability to add | as a path operator, so
I simply made "|" an optional ending character for a path identifier,
which is not the correct way to handle it.

Since there will be no EJBQL interaction, the porting of the 2.0 code
is the path of least resistance, and this code has now been running in
production environments for over a year with no known issues.

On Dec 12, 2007 1:28 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
> This is regarding Mike Kienenberger's comment from December 3 on
> CAY-929:
>
> "This is really a duplicate of CAY-560. There's selectTranslator
> support in there already for left (outer) joins. It's just a matter of
> eventually merging that code into 3.0 and, like you said, deciding how
> it fits into the grand plan of EJBQL."
>
>
> Mike,
>
> CAY-560 was sitting in the queue for a while, maybe cause it is too
> loaded... I was reviewing our options recently (now that EJBQL
> translator is in place), and figured it probably won't make sense (to
> convert SelectQuery to an EJBQL query internally on the short run
> anyways ... maybe we'll do it in 3.1 or something) . It would look
> approximately like this:
>
> SelectQuery -> EJBQLQuery -> SQLTemplate -> SQL
>
> The chain is too long.... So while EJBQLQuery is a good choice if you
> need expressions with outer joins, SelectTranslator will still benefit
> from outer join support in a number of cases that Ari described in
> Jira, where Cayenne can make an implicit decision about join semantics.
>
> Anton Sakalouski of ObjectStyle (you may remember him - he developed a
> PDF docs generator for Cayenne many years ago, although he hasn't been
> active in the community) was looking to implement a patch for
> SelectTranslator per CAY-929. So if you decide to go ahead with
> CAY-560, you'll have fewer things to port ;-)
>
> Andrus
>
>
>
>