Skip to main content

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

  • From: Oliver Gierke <ogierke@...>
  • To: Linda DeMichiel <linda.demichiel@...>
  • Cc: "jsr338-experts@..." <jsr338-experts@...>, Steve Ebersole <steve.ebersole@...>
  • Subject: [jsr338-experts] Re: JPQL: Sorting on optional references
  • Date: Thu, 30 Aug 2012 01:40:16 -0700
  • Accept-language: de-DE, en-US
  • Acceptlanguage: de-DE, en-US

Am 29.08.2012 um 20:53 schrieb Linda DeMichiel <linda.demichiel@...>:

>> I think it get's more obvious if you consider a more simple case:
>
>> select p from Person p
>
>> VS.
>
>> select p from Person p order by p.address.city
> 
> 
> If address is an embeddable, this query is legit.  If address is
> an entity (as in your original example, the order-by is not).

Re-reading 4.9 this becomes clear. I guess I've just been lead into thinking 
this is valid as persistence providers still allow this. They simply 
construct an inner join for the path expression. Not sure how strict these 
should be in terms of rejecting such expressions, especially as adding the 
order by leaks into the result content being returned.

Still I think that forcing a user to write:

select p from Person p left outer join p.address address order by address.city

where

select p from Person p order by p.address.city

The "it's currently defined as not allowed" aside, with the latter query and 
the metadata, everything is in place to build the query without the side 
effect.

> What the spec says (section 4.4.4) is:
> 
>    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.
> 
> Perhaps what this should say is:
> 
>    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 *contents* of
>    the result of the query.

What is the "value" here? Isn't it actually a value in the database? If we're 
considering database values already the inner join already has been executed 
and the result actually *gets* filtered, right?

> With order-by in play, there are two aspects to the result:
> 
> What is actually retrieved from the database ("contents of the
> result"), and how it is ordered.
> 
> In my view, the order-by clause should only affect the ordering of
> what is returned, not filter it.  That was the original intent,
> and why, for example, we disallow relationship joins in the orderby
> clause.

+100 for "not filter it". Regarding the "disallow": shouldn't the persistence 
provider then reject the query instead of executing it in a filtering way? 
Currently only the spec defines this as disallowed, but this is not reflected 
in the actual implementations.

Cheers,
Ollie

>> Am 29.08.2012 um 14:47 schrieb Steve Ebersole<steve.ebersole@...>:
>
>>> Not sure how this "side-effect" is "unpleasant and not easy to grasp".
>>> It is explicitly called out in the spec.
>>> 
>>> -1 for changing implicit joins to result in inner or outer joins
>>> depending on the mapping.  In such a case you can no longer see what
>>> will happen just by looking at the query itself, which in my opinion is
>>> far more "unpleasant and not easy to grasp".
>>> 
>>> 
>>> On 08/28/2012 07:44 AM, Oliver Gierke 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
 */



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

(continued)

[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