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