jsr338-experts@jpa-spec.java.net

[jsr338-experts] Re: improved SQL result set mapping

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Thu, 14 Apr 2011 15:22:50 -0700

On 4/14/2011 3:20 PM, Evan Ireland wrote:
> Linda,
>
> Can you give an example of usage of ConstructorResult.
>
> Since constructor parameters are positional (unnamed at runtime), I presume
> that you would intend to use positional binding?
>

Yes, exactly.

>> -----Original Message-----
>> From: Linda DeMichiel [mailto:linda.demichiel_at_oracle.com]
>> Sent: Friday, 15 April 2011 10:06 a.m.
>> To: jsr338-experts_at_jpa-spec.java.net
>> Cc: linda.demichiel_at_oracle.com
>> Subject: [jsr338-experts] Re: improved SQL result set mapping
>>
>>
>>
>> On 4/13/2011 5:16 PM, Linda DeMichiel wrote:
>>> Another pending item in the query area is the ability to use
>>> constructors for non-entity results of native queries.
>>>
>>> Here's another strawman proposal to get the discussion started:
>>>
>>>
>>> To support the use of constructors in SqlResultSetMapping, we could
>>> define a ConstructorResult mapping:
>>>
>>> @Target(value={})
>>> @Retention(value=RUNTIME)
>>> public @interface ConstructorResult {
>>> Class targetClass();
>>> ColumnResult columns();
>> Just noticed the typo in the above. This should have been
>> ColumnResult[] columns();
>>
>> Any feedback?
>>
>> thanks,
>>
>> -Linda
>>
>>> }
>>>
>>>
>>> This could be used in combination with @EntityResult and
>> @ColumnResult
>>> in SQLResultSetMapping:
>>>
>>> @Target({TYPE})
>>> @Retention(RUNTIME)
>>> public @interface SqlResultSetMapping {
>>>
>>> /**
>>> * The name given to the result set mapping, and used to refer
>>> * to it in the methods of the Query API.
>>> */
>>> String name();
>>>
>>> /** Specifies the result set mapping to entities. */
>>> EntityResult[] entities() default {};
>>>
>>> /** Specifies the result set mapping to constructors. */
>>> ConstructorResult[] classes() default {};
>>>
>>> /** Specifies the result set mapping to scalar values. */
>>> ColumnResult[] columns() default {};
>>> }
>>>
>>>
>>> We should also be more specific about the relationship among the
>>> shape of the SELECT list, the specified SqlResultSetMapping, and the
>>> order in which results are returned by the execution of the query.
>>> This is currently undefined in the spec.
>>>
>>> For example:
>>>
>>> When a SqlResultSetMapping specifies more than one mapping
>> type (i.e.,
>>> more than one of EntityResult, ConstructorResult,
>> ColumnResult), then
>>> for each row in the SQL result, the query execution will
>> result in an
>>> Object[] whose elements are as follows, in order: any entity results
>>> (in the order in which they are defined in the entities
>> element); any
>>> instances of classes corresponding to constructor results (in the
>>> order defined in the classes element); and any instances
>> corresponding
>>> to column results (in the order defined in the columns element).
>>>
>>> Another issue is that when a column is not mapped as an entity
>>> attribute, there is currently no way to specify the type to
>> be returned
>>> by the query (e.g., Timestamp instead of Date).
>>>
>>> I suggest that we address this by adding another element to
>>> @ColumnResult, e.g., type, which would default to void.class for
>>> default JDBC type mapping.
>>>
>>>
>>> Feedback, please!
>>>
>>> thanks,
>>>
>>> -Linda
>>>
>