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
This archive was generated by hypermail 2.0.0 : Sat Aug 19 2006 - 08:49:19 EDT