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
>