Skip to main content

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

  • From: Werner Keil <werner.keil@...>
  • To: jsr338-experts@...
  • Subject: [jsr338-experts] Re: JPQL: Sorting on optional references
  • 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@...> 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
 */




[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
 
 
Close
loading
Please Confirm
Close