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