Where would the @ObjectResult annotation be placed? On the non-entity object itself?
I haven't thought about that, that might be interesting. Though it does not cover cases where people want alternative result structures than POJOs (like maps or something else).
On 28 avr. 2011, at 16:09, Evan Ireland wrote:
> Emmanuel,
>
> What about allowing an "ObjectResult" mapping annotation that allows NAMED
> (not positional) mapping of SQL result set columns to FIELDS of non-entity
> result classes?
>
> (Linda has already encouraged me to write this up as a proposal, but I've
> not got around to that yet. Just been on vacation, and now trying to catch
> up with my main job).
>
>> -----Original Message-----
>> From: Emmanuel Bernard [mailto:emmanuel.bernard_at_jboss.com]
>> Sent: Thursday, 28 April 2011 10:58 p.m.
>> To: jsr338-experts_at_jpa-spec.java.net
>> Subject: [jsr338-experts] Re: improved SQL result set mapping
>>
>> An entirely different twist / solution to this problem could
>> be to provide a customizable post processing step to
>> transform the results returned by a query.
>> This could be considered an orthogonal feature though.
>>
>> //JPA 2 API
>> interface ResultTransformer {
>> public Object transformTuple(Object[] tuple, String[]
>> aliasOrColumnName);
>> }
>>
>> //user implementation
>> class ConstructorResultTransformer {
>> private final Constructor constructor;
>>
>> public ConstructorResultTransformer(Constructor constructor) {
>> this.constructor = constructor;
>> }
>>
>> public Object transformTuple(Object[] tuple, String[]
>> aliasesOrColumnNames) {
>> //TODO try catch for *Exception
>> return constructor.newInstance( tuple );
>> }
>> }
>>
>> This is not limited to constructors, one can think of many
>> use cases like:
>> - returning maps
>> - setting values based on setters rather than constructors
>>
>> This is not a fleshed out proposal, a few areas need to be
>> worked out, including:
>> - how is aliasesOrColumnNames exactly defined
>> - how to make it so it plays well in the type system of a TypedQuery
>>
>> Emmanuel
>>
>> On 14 avr. 2011, at 02:16, 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();
>>> }
>>>
>>>
>>> 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
>>>
>>
>>
>>
>