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 <[EMAIL PROTECTED]> 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
