Yeah, I'm trying to see if I can find a short-term solution rather
than having to reimplement everything all at once.
I have everything working with the + notation now, except for the
split and null issues.
It looks like this will work to handle the split implementation, so
"+" would mean both split and outer join in my use case. I will
hopefully know sometime tomorrow :-)
I think what you proposed is workable, but there's some unanswered
questions, like how splits would be configured. I suppose it'd have
to be done manually.
I also need to convert from Oracle 8 notation to the generic notation.
(Oracle 8 doesn't allow outer joins with OR), but I think this will
be pretty trivial compared to what's been done so far.
If I can get all of this working, then providing the EJB QL-compatible
sytax down the road shouldn't be too difficult.
On 8/20/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
>
> On Aug 20, 2006, at 10:32 PM, Mike Kienenberger wrote:
>
> > I didn't state how a user would configure it, only how it could be
> > processed if it was specified.
>
> Ah, ok.
>
> > Right now, I'm leaning on making
> > join semantics represent this. So a query can be (inner|outer) +
> > (split|nosplit). Realistically, that's probably only inner, inner
> > w/split, and outer w/split as the three options.
>
> I guess that's JPA join semantics?
>
> > Your original idea of "+" and "|" works as part of the path expression
> > works for me as well.
>
> I don't mind this as an alternative. I just thought it would be cool
> if we find synergy between EJB QL and our current SelectQuery (and I
> think we came close). If it turns out that we are stretching it too
> much, we can use this semantics instead.
>
> Andrus
>
>
This archive was generated by hypermail 2.0.0 : Sun Aug 20 2006 - 15:38:33 EDT