Hi Gordon,
I agree,. That means the downcast is valid if the expression has a type
that is a superclass of the class following the AS keyword.
An invalid downcast should result in an exception thrown by the query
compiler not the query runtime.
Regards Michael
> Hello Michael,
> The question become what is an invalid downcast? In the below
> example it is Employee.project that is being downcast and both
> sub-expressions apply an applicable downcast. If one of the downcasts
> was to a class that was not a sub-class of Employee.project's type
> then that would be an invalid downcast and should result in an exception.
>
> During evaluation of the restriction (say 'TREAT(p AS
> SmallProject).name LIKE "Persist%" ') if the type is not SmallProject
> or one of its sub-classes) then the restriction should evaluate to
> false but the downcast in this case is not invalid.
>
> --Gordon
>
> Michael Bouschen wrote:
>> Hi Linda, hi all,
>>
>> I would like to second what Matthew replied: an invalid downcast
>> should cause the query condition to evaluate to false.
>>
>> Otherwise the example Linda gave in her initial mail will result in
>> an exception in any case:
>>
>> SELECT e FROM Employee JOIN e.projects p
>> WHERE TREAT(p AS LargeProject).budget > 1000 OR
>> TREAT(p AS SmallProject).name LIKE "Persist%" OR ...
>>
>> For LargeProject instances the second TREAT expression will cause the
>> query to fail with an exception, where for SmallProject instances it
>> is the first TREAT expression causing the exception.
>>
>> Regards Michael
>>
>>> Responses inline...
>>>
>>>
>>>> SQL supports this via the TREAT ... AS operator:
>>>> TREAT (expression AS datatype)
>>>> where datatype is a subtype of the static type of the expression.
>>>>
>>>>
>>> ok
>>>
>>>
>>>> An open issue however is the handling of the case where the
>>>> instance passed to TREAT is not of the same type or a subtype of the
>>>> specified datatype.
>>>>
>>>> Databases seem to differ as to whether the result should be null or
>>>> whether an error is raised. We need to decide this as well.
>>>>
>>>>
>>> It seems appropriate to me that in the event that the downcast is
>>> invalid, it should cause all query conditions involving the identifier
>>> that is being downcast to evaluate to false. I don't think an error
>>> should be raised. This would also prevent our having to worry about
>>> attempting to return results whose specification includes instances or
>>> reachable properties of instances of the downcast type (as in your
>>> first example).
>>>
>>>
>>>> The Criteria API already provides the Expression method
>>>> <X> Expression<X> as(Class<X> type);
>>>>
>>>>
>>> Same semantics as the string query form, IMHO.
>>>
>>> -matthew
>>>
>>>
>>
>>
>> --
>> *Michael Bouschen*
>> *Prokurist*
>>
>> akquinet tech_at_spree GmbH
>> Bülowstr. 66, D-10783 Berlin
>>
>> Fon: +49 30 235 520-33
>> Fax: +49 30 217 520-12
>> Email: michael.bouschen_at_akquinet.de
>> Url: www.akquinet.de <http://www.akquinet.de>
>>
>> akquinet tech_at_spree GmbH, Berlin
>> Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
>> Amtsgericht Berlin-Charlottenburg HRB 86780 B
>> USt.-Id. Nr.: DE 225 964 680
--
*Michael Bouschen*
*Prokurist*
akquinet tech_at_spree GmbH
Bülowstr. 66, D-10783 Berlin
Fon: +49 30 235 520-33
Fax: +49 30 217 520-12
Email: michael.bouschen_at_akquinet.de
Url: www.akquinet.de <http://www.akquinet.de>
akquinet tech_at_spree GmbH, Berlin
Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680