Hello Mauro,
See inline
On 11/01/2016 5:04 AM, Mauro Molinari
wrote:
Hi Chris,
thank you very much, this works! I would be curious to know why
other methods on DatabaseMapping don't work as I would expect
(like isOwned()... seems to return false for both owned and
non-owned relationships, or the already mentioned
getRelationshipPartnerAttributeName() and
getRelationshipPartner(), which always return null), anyway my
problem is solved.
I would just add that I'm not yet convinced that the problem I
described is not a 'bug'. IMHO (I'm not a spec expert though),
the specification part you cited says:
"Path _expression_ navigability is composed using “inner join”
semantics. That is, if the value of a non-terminal field in the
path _expression_ is null, the path is considered to have no
value, and does not participate in the determination of the
result."
But in my case, when I'm expressing (through a Criteria API
query) the following:
WHERE First.second IS NULL
I'm not navigating the relationship (like I would if I were
writing something like First.second.foo IS NULL). Also, "second"
is not a non-terminal field in the path _expression_, on
the contrary it's exactly the terminal field! So I'm not
convinced the use of an inner join here is justified by the
above statement.
First.second is a path _expression_, and the definition states
"navigability is composed using “inner join” semantics". The
statement you site is meant as example showing what this means, but
it did not attempt to explain what it means when the terminal side
is null and having to differentiate entities from scalar fields.
Much of this discussion already occurred with bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=246211
I'm still convinced that the actual
result when using "WHERE First.second IS NULL" should not differ
if the mapping says that First owns the relationship or if it
says that Second owns it. It's incoherent.
I agree, and I am not stating that they should differ. What I'm
stating is that the optimized behavior you are seeing so that it
sometimes gives you the desired results is actually against what the
specification states should happen. Using "WHERE First.second IS
NULL" should never be true according to the specification, as nulls
are filtered out through an inner join. EclipseLink chose to
implement an optimization on some mappings that do not require a
join but did not bother dealing with the inconsistencies of this
edge case as this edge case really is disallowed by the
specification - the JPA compliant way to write the query to get the
results you want is to force a left outer join in the query.
If you still think it's a
specification problem, then I would appreciate if my report is
forwarded to the specification guys.
I am not involved in the specification so it is better if you
forward your request/report directly.
Thanks again for your help!
Mauro
Il 08/01/2016 19:15, christopher delahunt ha scritto:
I got a bit muddled while editing the code.
Standard 1:1 relationship in JPA is a foreignKeyRelationship in
EclipseLink, and a join is NOT required.
MappedBy relationship in JPA is a targetForeignKeyRelationship
in EclipseLink, and a join IS required.
DatabaseMapping mapping = ((SingularAttributeImpl)
attribute).getMapping();
if (mapping.isOneToOneRelationship() &&
!((OneToOneMapping)mapping).isForeignKeyRelationship()) {
cq.where(cb.isNull(root.join(First_second,
JoinType.LEFT)));
cq.where(cb.isNull(root.get(First_second)));
I haven't tested it, so it may need some work to compile.
Best Regards,
Chris
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
