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