users@jpa-spec.java.net

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

From: Werner Keil <werner.keil_at_gmail.com>
Date: Tue, 28 Aug 2012 16:29:55 +0200

Thanks for correcting that.

If it wasn't for the typo, you probably wouldn't have inspired me to
highlight the "nullable" issues. Maybe should go into separate thread to
ensure better visibility?

Werner

On Tue, Aug 28, 2012 at 4:27 PM, Oliver Gierke <ogierke_at_vmware.com> wrote:

> Hi all,
>
> sorry for that glitch. I essentially meant the "optional" attribute. So
> the sample could should have read:
>
> @Entity
> class Person {
>
> @OneToOne(optional = true) Address address;
> }
>
> @Entity
> class Address {
> String city;
> }
>
> Note that for the …ToOne annotation the optional flag defaults to true, so
> unless you're explicitly changing this to false (and thus change the
> semantics of the modeling completely) you're likely to run into the
> situation described.
>
> Cheers,
> Ollie
>
> Am 28.08.2012 um 15:12 schrieb Werner Keil <werner.keil_at_gmail.com>:
>
> > 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 @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;
> > }
> >
> > 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>
> 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
> > * @param phone +49-351-30929001
> > * @param fax +49-351-418898439
> > * @param skype einsdreizehn
> > * @see http://www.olivergierke.de
> > */
> >
> >
>
> --
> /**
> * @author Oliver Gierke - Senior Member Technical Staff
> *
> * @param email ogierke_at_vmware.com
> * @param phone +49-351-30929001
> * @param fax +49-351-418898439
> * @param skype einsdreizehn
> * @see http://www.olivergierke.de
> */
>
>