JPQL has been very SQL like and function like since the beginning. We
should continue to follow that same pattern as that is what users will
be familiar with.
--Gordon
Emmanuel Bernard wrote:
> Note that we could reduce the support of INSTANCEOF in the where
> clause to something much similar to the current TREAT proposal
>
> WHERE (p INSTANCEOF LargeProject).budget > 1000
>
> So if I summarize:
> - there is a 'variable INSTANCEOF Type' approach that's a bit more OO
> - there is a INSTANCEOF(variable, Type) approach with its
> cousin INSTANCEOF(variable AS Type) that are more SQL
>
> And once that's chosen, there is the name of the operator / function:
> - TREAT
> - INSTANCEOF
> - IS
>
> Emmanuel
>
> On 14 mars 2011, at 18:47, Gordon Yorke wrote:
>
>> My concern with IS or INSTANCEOF is those keywords already have an
>> associated meaning and the TREAT functionality is more complex. It
>> is a combination of an instanceof and a cast. IS or INSTANCEOF
>> implies that it is an equality expression (ie "TYPE(p) =
>> SmallProject") and fails to indicate that the type of p has changed
>> in the expression. If the type is not changed then the expression
>> becomes confusing and difficult to read. Parsing and validation
>> becomes more challenging and far too much emphasis is place on the
>> location of round brackets which will greatly impact readability.
>>
>> I do not think there is any concerns using TREAT as users are aware
>> that this JPQL and JPQL has its own semantics.
>> --Gordon
>>
>>
>> Emmanuel Bernard wrote:
>>> Yep IS is nicer.
>>> I think we can implement compile time checking.
>>> For sure in the example I've given. The use of a subproperty can only be used in a AND predicate branch where there is a IS T and T or one of its superclass hosts the subproperty. (Sorry for my barbarisms, I hope you get the idea).
>>>
>>> On 13 mars 2011, at 23:06, Evan Ireland wrote:
>>>
>>>
>>>> Emmanuel,
>>>>
>>>> I would suggest "IS" rather than "INSTANCEOF".
>>>>
>>>> However, doesn't this cause the problem that the expression "p.budget"
>>>> cannot be type-checked before actually executing the query. Do we want
>>>> JPA-QL to have to defer some type checking until query execution time?
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Emmanuel Bernard [mailto:emmanuel.bernard_at_jboss.com]
>>>>> Sent: Monday, 14 March 2011 11:00 a.m.
>>>>> To: linda.demichiel_at_oracle.com
>>>>> Cc: jsr338-experts_at_jpa-spec.java.net
>>>>> Subject: [jsr338-experts] Re: query improvements: downcasting
>>>>>
>>>>> Like some here, I am not a fan of TREAT as a method name.
>>>>>
>>>>> Why not try and explore the more OO approach of using instanceof:
>>>>> - it could be more flexible
>>>>> - it is clearer to OO people
>>>>> - w are not tied to the inconsistencies in DBs
>>>>> implementations of TREAT
>>>>>
>>>>> //notice the use of parenthesis
>>>>> WHERE ( INSTANCEOF(p, LargeProject) AND p.budget > 1000 )
>>>>> OR ( INSTANCEOF(p, SmallProject ) AND p.name <http://p.name>
>>>>> LIKE "Persist%" )
>>>>> OR p.description LIKE "COST OVERRUN"
>>>>>
>>>>> //alternative syntax
>>>>> WHERE ( p INSTANCEOF LargeProject AND p.budget > 1000 )
>>>>> OR ( p INSTANCEOF SmallProject AND p.name <http://p.name>
>>>>> LIKE "Persist%" )
>>>>> OR p.description LIKE "COST OVERRUN"
>>>>>
>>>>>
>>>>> On 11 mars 2011, at 21:23, Linda DeMichiel wrote:
>>>>>
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Outside of a few more minor aspects, it looks like we're on the same
>>>>>> page with regard to TREAT, so I'll start trying to spec it out more
>>>>>> formally.
>>>>>>
>>>>>> Here's where I think we are:
>>>>>>
>>>>>> 1) We'll support the use of TREAT for downcasting within path
>>>>>> expressions in the FROM and WHERE clauses.
>>>>>>
>>>>>> 2) If the target type is not a (proper or improper) subtype of
>>>>>> the static type of the first argument, the query is invalid (and
>>>>>> an exception is thrown).
>>>>>>
>>>>>> 3) If during query execution the first argument is not a (proper or
>>>>>> improper) subtype of the target type, we'll assume "null
>>>>>>
>>>>> semantics"--
>>>>>
>>>>>> i.e. in the case of a join, the referenced object does not
>>>>>>
>>>>> participate
>>>>>
>>>>>> in the result, and in the case of a restriction, the associated
>>>>>> predicate is false.
>>>>>>
>>>>>> 4) We'll add treat() to the criteria API
>>>>>>
>>>>>> BTW, I have a suspicion that trying to integrate this into the
>>>>>> spec will reveal a few more issues.
>>>>>>
>>>>>> If you disagree with the above, please speak now.
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> -Linda
>>>>>>
>>>>>> p.s. I am still regarding the exact name as potentially subject to
>>>>>> change, but that is the easiest part to change later in the spec :-)
>>>>>>
>>>>>>
>>>>>> On 3/11/2011 8:51 AM, Matthew Adams wrote:
>>>>>>
>>>>>>> On Fri, Mar 11, 2011 at 10:11 AM, Rainer Kwesi Schweigkoffer
>>>>>>> <kwesi_at_sap.com> wrote:
>>>>>>>
>>>>>>>> Matthew Adams, am 10 Mar 2011 hast Du um 17:12 zum Thema
>>>>>>>>
>>>>> "[jsr338-experts] Re: query improvements: downcast" geschrieben :
>>>>>
>>>>>>>>> If so, then I would restate **for the deferred,
>>>>>>>>> not-currently-specified projection use of TREAT AS**
>>>>>>>>>
>>>>> that if either
>>>>>
>>>>>>>>> Book is not assignment-compatible with Product or the
>>>>>>>>>
>>>>> filter results
>>>>>
>>>>>>>>> in type-incompatible instances with the projection expression, an
>>>>>>>>> exception is thrown.
>>>>>>>>>
>>>>>>>> Do you see a specific use case that would require to
>>>>>>>>
>>>>> admit TREAT AS for
>>>>>
>>>>>>>> the select clause as well ?
>>>>>>>>
>>>>>>>>
>>>>>>> I suppose not.
>>>>>>> Theoretically, using TREAT AS in the projection (the
>>>>>>>
>>>>> select clause) is
>>>>>
>>>>>>> not required. If the user wants to exclude certain types from the
>>>>>>> query, the mechanism by which I'd recommend that they do
>>>>>>>
>>>>> it would be
>>>>>
>>>>>>> to use FROM ... TREAT ... AS. To use SELECT ... TREAT ...
>>>>>>>
>>>>> AS requires
>>>>>
>>>>>>> that the filter only return objects of the expected type;
>>>>>>>
>>>>> if they want
>>>>>
>>>>>>> objects of that type, then why not just use FROM ... TREAT
>>>>>>>
>>>>> ... AS? It
>>>>>
>>>>>>> seems like they're just asking for an exception to be
>>>>>>>
>>>>> thrown if they
>>>>>
>>>>>>> use SELECT ... TREAT ... AS. The only behavior that
>>>>>>>
>>>>> they'd get with
>>>>>
>>>>>>> SELECT ... TREAT ... AS is either an exception if their query was
>>>>>>> wrong or the same behavior as FROM ... TREAT ... AS. Seems
>>>>>>> unnecessary to me.
>>>>>>> Let's see if anyone comes up with a use case for SELECT
>>>>>>>
>>>>> ... TREAT ...
>>>>>
>>>>>>> AS that can't be solved with a FROM ... TREAT ... AS. I'd be
>>>>>>> surprised if there were.
>>>>>>> -matthew
>>>>>>>
>>>>>
>>>
>>>
>