Hi Emmanuel,
How do I use INSTANCEOF in the FROM clause?
Would it allow for multiple downcasts, e.g.
SELECT c
FROM Customer c JOIN treat(c.order AS BigOrder) bigOrder
JOIN treat(bigOrder.exclusiveProduct AS Yacht) y
WHERE y.countryRegistered = "Spain" OR bigOrder.cost > 10000000
thanks,
Linda
On 3/13/2011 2:59 PM, Emmanuel Bernard wrote:
> 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
>