On 3/13/2011 2:54 PM, Emmanuel Bernard wrote:
> On 11 mars 2011, at 17:51, 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.
>
> I can see this use case being acceptable
>
> class Item {
> }
>
> class Book extends Item {
> String getTitle();
> }
>
> class Toaster extends Item {
> String getName();
> }
>
> SELECT COALESCE( TREAT(o.product AS Book).title, TREAT(o.product AS Toaster).name ) ...
Yes -- that's a nice example.