Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] How to get the "mappedBy" attribute name of a relation Attribute in a OneToOneMapping

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)));
} else {
  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


Back to the top