Andy Jefferson added a comment - 10/Dec/07 06:20 PM

Andy Jefferson added a comment - 10/Dec/07 06:20 PM The code is missing a basic step - compile the FROM and get the join aliases and what they alias to. Then we should do a pre-compile step on all subsequent compiled strings and replace any of the aliases with what they are aliasing. For example select Distinct c FROM Customer c LEFT OUTER JOIN c.work workAddress where workAddress.zip IS NULL compileFrom would extract "workAddress" aliased to "c.work". When we compile the filter we would do a pre-compile and get c.work.zip IS NULL This is then compiled as normal and should work fine. Any problem with this strategy ?

Andy Jefferson added a comment - 10/Dec/07 09:52 PM

Andy Jefferson added a comment - 10/Dec/07 09:52 PM Actually doing that we end up with things like "c.lineItems.price.subItems.currency" so going through container fields, which is invalid for JPA/JDO. So maybe better to do internally as variables. The current ClassExpression.join(...) is currently a no-op so what is this planned to do in the future when implemented?

Andy Jefferson added a comment - 16/Jan/08 06:14 PM

Andy Jefferson added a comment - 16/Jan/08 06:14 PM No sign of work on this, so assigning to myself.

Andy Jefferson added a comment - 18/Jan/08 01:06 PM

Andy Jefferson added a comment - 18/Jan/08 01:06 PM Marking as fixed since all JOIN issues in the JPA TCK are resolved. TODO in the code for use of Maps in joins, but no JPA TCK tests for that so leave til after 1.2.0