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
>> 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
>> 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
>>
>>
>>
>