From: Werner Keil <werner.keil_at_gmail.com>
Date: Wed, 9 Mar 2011 01:14:11 +0530

Linda/all,

Regarding the null value, there seems a Java SE version (most likely even 7?
[?]) handling those more gracefully, but I too wouldn't rely on that by
returning null. I am just going (in a prre-JPA project) through 2k+ places
in a code, where similar stuff (e.g. returning null and no warning or log
entry) happens...

Werner

On Tue, Mar 8, 2011 at 8:49 PM, Gordon Yorke <gordon.yorke_at_oracle.com>wrote:

> Hello All,
>
> 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.
>>
> An error is the better approach. Debugging null would be a challenge.
> --Gordon
>
>
>
> Linda DeMichiel wrote:
>
>> As promised, we'll kickoff our work with some of the hopefully easier
>> items to get us warmed up. We'll start with some topics in the query
>> area.
>>
>> First up -- downcasting.
>>
>>
>> We've gotten a number of requests to support a downcasting functionality
>> in the query language. This is useful particularly for polymorphic
>> relationships where the intent is to access subtype-specific attributes.
>>
>> SQL supports this via the TREAT ... AS operator:
>>
>> TREAT (expression AS datatype)
>>
>> where datatype is a subtype of the static type of the expression.
>>
>>
>> The extension of this syntax to JPQL would be straightforward.
>>
>> For example,
>>
>> SELECT b.name, b.ISBN
>> FROM Order o JOIN TREAT(o.product AS Book) b
>>
>> SELECT e FROM Employee e JOIN TREAT(e.projects AS LargeProject) lp
>> WHERE lp.budget > 1000
>>
>> SELECT e FROM Employee JOIN e.projects p
>> WHERE TREAT(p AS LargeProject).budget > 1000 OR
>> TREAT(p AS SmallProject).name LIKE "Persist%" OR
>> p.description LIKE "COST OVERRUN"
>>
>>
>> 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.
>>
>> I think the above examples illustrate the utility of defining the
>> semantics as providing a filtering as well as downcasting semantics
>> (i.e., taking the approach of using null semantics).
>>
>> The Criteria API already provides the Expression method
>> <X> Expression<X> as(Class<X> type);
>>
>> However, note that the definition of this explicitly states: "This
>> method does not cause type conversion: the runtime type is not
>> changed. Warning: may result in a runtime failure. "
>>
>>
>> Opinions?
>>
>> thanks,
>>
>> -Linda
>>
>

-- 
 Werner Keil | UOMo Lead | Eclipse Foundation | Agile Coach, Principal
Consultant | *emergn* limited
590 Madison Avenue. New York. NY 10022 | 68 Lombard Street. London EC3V 9LJ
UK
US Toll Free:  +1-877.964.1981 | Worldwide Toll Free:  +800.225.53482
Skype: werner.keil|www.emergn.com | Reshaping IT
* STP Conference & Expo: March 24, 2011, Nashville, TN. Werner Keil, Agile
Coach and Principal Consultant, will be presenting "Agile Test Automation"
* Great Indian Developer Summit: April 21, 2011, Bangalore, India. Werner
Keil, Agile Coach and Principal Consultant, will be presenting "Java EE 7,
CDI and Trusted Java"