Skip to main content

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

  • From: Linda DeMichiel <linda.demichiel@...>
  • To: jsr338-experts@...
  • Cc: Werner Keil <werner.keil@...>
  • Subject: [jsr338-experts] Re: JPQL: Sorting on optional references
  • Date: Wed, 29 Aug 2012 11:59:14 -0700
  • Organization: Oracle Corporation



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 *@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@... 
<mailto:ogierke@...>> 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@... <mailto:ogierke@...>
      * @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
      */




[jsr338-experts] JPQL: Sorting on optional references

Oliver Gierke 08/28/2012

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

Werner Keil 08/28/2012

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

Oliver Gierke 08/28/2012

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

Werner Keil 08/28/2012

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

Oliver Gierke 08/28/2012

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

Werner Keil 08/28/2012

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

Linda DeMichiel 08/29/2012

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

Steve Ebersole 08/29/2012

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

Oliver Gierke 08/29/2012

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

Steve Ebersole 08/29/2012

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

Oliver Gierke 08/29/2012

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

Steve Ebersole 08/29/2012

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

Linda DeMichiel 08/29/2012

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

Michael Bouschen 08/29/2012

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

Linda DeMichiel 08/30/2012

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

Oliver Gierke 08/30/2012

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

Steve Ebersole 08/30/2012
 
 
Close
loading
Please Confirm
Close