Skip to main content

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

  • From: Oliver Gierke <ogierke@...>
  • To: "jsr338-experts@..." <jsr338-experts@...>
  • Subject: [jsr338-experts] Re: JPQL: Sorting on optional references
  • Date: Tue, 28 Aug 2012 07:52:01 -0700
  • Accept-language: de-DE, en-US
  • Acceptlanguage: de-DE, en-US

Sounds good. To be honest, I didn't quite get the connection. And on 

> @OneToOne(nullable = true) @NotNull @NonNull @Nullable(true) Address 
> address;

it threw me out of the corner eventually :)

Cheers,
Ollie

Am 28.08.2012 um 16:29 schrieb Werner Keil <werner.keil@...>:

> 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@...> 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@...>:
> 
> > 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@...> 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@...
> >  * @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@...
>  * @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@...
 * @param phone +49-351-30929001
 * @param fax   +49-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
 
 
Close
loading
Please Confirm
Close