users@jpa-spec.java.net

[jpa-spec users] [jsr338-experts] Re: JPQL: Sorting on optional references

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Wed, 29 Aug 2012 11:59:14 -0700

On 8/28/2012 6:12 AM, Werner Keil wrote:
> Oliver/all,
>
> Thanks for pointing that out.
> While the actual query may not be changed, you can sure contradict the *nullable = true* by adding a *_at_NotNull
> *annotation from Bean Validation to it. The two are legitimate together:
> http://stackoverflow.com/questions/2725111/hibernate-onetoone-notnull
>
> Java 7 and EE7 most likely give you a Runtime Exception, maybe some IDE warning if it provides JPA support, but the
> compiler itself is not going to do much about it.
>
> JSR 308, so far scheduled for Java 8 aims to change that:
> http://types.cs.washington.edu/jsr308/
>
> Unfortunately, both the Spec Leads of 308 deny any responsibility or ownership of checker annotations, nor have the
> architects at Oracle so far take precautions to avoid a big mess like this
>
> @Entity
> class Person {
>
> @OneToOne(nullable = true) @NotNull @NonNull @Nullable(true) Address address;
> }

This is obviously an ill-formed application :-) However, please note
that there is nothing preventing anyone from writing this kind of
nonsense using bean validation constraints alone.

>
> BeanValidation as of now
> Checker Annotations based on JSR 308 as of now (from Java 8)
>
> Given a combination of Java EE 6/7 and JSR 308 this would be perfectly fine. Most likely the two checkers would cause a
> compiler error already, but one alone, let's say @Nullable(true) instead of a sensible integration with all existing
> stuff will increase the big mess around these annotations already present
> http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use
>
> I probably forgot @Nonnull as of JSR 305 which at the moment polutes the JDK already, but has no effect. At the very
> least, instead of having people stuff in more annotations of all different kinds, either @Nonnull should be killed with
> Java 8 and replaced with something else, or it should be used. Most likely the conflict with BeanValidation (which is
> primarily used by JPA) would be unavoidable then.
>
> Sorry to hijack the thread, I hope, at least Linda keeps an eye on that or plans to do something about it, so that we
> can avoid annotation chaos we inherited in other areas, e.g. @Inject vs. other legacy approaches, etc.?
>
> Thanks,
> Werner
>
> On Tue, Aug 28, 2012 at 2:44 PM, Oliver Gierke <ogierke_at_vmware.com <mailto:ogierke_at_vmware.com>> wrote:
>
> Hi all,
>
> I just came across a JPQL spec scenario that seems to be a bit weird and I wonder whether there's something we
> should do about. Suppose you have a Person with optional Addresses:
>
> @Entity
> class Person {
>
> @OneToOne(nullable = true) Address address;
> }
>
> @Entity
> class Address {
> String city;
> }
>
> Now the query scenario here is that we'd like to get all Persons sorted by the Address' city:
>
> select p from Person p left outer join p.address order by p.address.city
>
> Surprisingly, this query will not return Persons not having an Address associated for the following reason: JPA 2.0
> spec section 4.4.4. defines path expressions as follows:
>
> > 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.
>
> That apparently forces persistence providers into adding an additional inner join to the query which rules out the
> Persons without Addresses in the first place. I think it's rather unfortunate to have this path expression
> definition applied to order by clauses as users probably don't expect adding a sort definition would strengthen the
> actual query criteria. So here are my questions:
>
> 1. Why was the path expression navigability defined as such in the first place and not as considering the mapping
> metadata (nullable = true -> outer join, nullable = false -> inner join). Not saying this is utterly wrong, just
> want to understand the probably available reasons.
> 2. Should/can this definition be changed to require consideration of the mapping information? The path expression
> definition is very much written with the purpose of defining selection criterias which is what they are effectively
> not used for when used in ORDER BY clauses. The current state leaves JPQL in the weird state that adding a sorting
> criteria affects the returned items not only in order but also in which items are returned at all, a side-effect
> which is unpleasant and not easy to grasp.
>
> Cheers,
> Ollie
>
> --
> /**
> * @author Oliver Gierke - Senior Member Technical Staff
> *
> * @param email ogierke_at_vmware.com <mailto:ogierke_at_vmware.com>
> * @param phone +49-351-30929001 <tel:%2B49-351-30929001>
> * @param fax +49-351-418898439 <tel:%2B49-351-418898439>
> * @param skype einsdreizehn
> * @see http://www.olivergierke.de
> */
>
>