On Aug 18, 2006, at 11:30 PM, Mike Kienenberger wrote:
Now I was all ready to keep joins associated with Expressions. Why
switch them back?
It is hard to design it right from the first shot. But I hope we are
getting closer now.
It looks like each join in the JPA spec is associated with an
expression as well.
No, there is a separation. Keep in mind that Cayenne expressions
approximate just the WHERE clause in SQL, while EJBQL is SELECT+FROM
+WHERE+..., i.e. the entire SQL query. Joins are defined in the FROM
clause (that allows to define precise join splits and semantics of
each join).
If we are going to put the join on the query, (or even if we are not),
how do you see the actual usage looking from the cayenne side?
Let me rewrite the example I mentioned before in terms of proposed
SelectQuery API:
SelectQuery q = new SelectQuery(Painting.class);
q.setQualifier("x.artistName = null or y.artistName = 'artist6'");
// *** NEW SUGGESTED API
q.setJoins("LEFT OUTER JOIN toArtist x, LEFT OUTER JOIN toArtist y");
Will expressions now have table alias prefixes which are matched up to
the aliases specified in the join parameters?
Yes - optionally.
Or do we want to switch entirely to the JPA format of LEFT OUTER JOIN
AS x FETCH exp? with the join type defaulting to inner if not
specified.
Essentially everything will continue to work the way it does now, and
only when you need custom splits and/or OUTER joins, "setJoins"
method will be used with a JPA join string.
Finally, is there a difference between LEFT OUTER JOIN and LEFT JOIN
in the JPA specs?
No, they are the same ("OUTER" is an optional keyword - "LEFT"
implies "OUTER").
It seems like no matter how we approach it, there will be a different
syntax going forward. If that's the case, maybe we should plan on
using the JPA syntax where possible.
I think this will happen over time ...
I started on the full EJB QL parser grammar last night (I didn't have
internet access till now, so I couldn't share anything). I guess the
next step would be a JpaQuery (or EJBQLQuery) that includes a spec-
compliant query string and translates to SelectQuery (if it happens
to be a select) during execution. And later we may merge the two if
this turns out to be possible.
Andrus
