Hi Linda, all,
Linda DeMichiel, am 13 Apr 2011 hast Du um 17:16 zum Thema "[jsr338-experts] improved SQL result set mapping" geschrieben :
> @Target(value={})
> @Retention(value=RUNTIME)
> public @interface ConstructorResult {
> Class targetClass();
> ColumnResult[] columns();
> }
One could think of EntityResult[] entities here as well. This would
impose a restriction on the ordering of constructor parameters
(entities either first or last), however, I think one could live with
that. Unfortunately, annotations may not inherit from each other.
> @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 {};
> }
Looks good to me.
> 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).
This, actually, has been my understanding of the spec. Yet it would be
good to make that explicit. Maybe we should also explicitly say that
the ordering in the SQL select clause is irrelevant since the binding
is done via names. We might want to add something about unmmapped
columns, too. Currently, imho, we only state for the opposite case that
the result is undefined.
I would also welcome if we became a bit clearer about the positional
parameter binding, i.e., that the parameters themselves follow the SQL
syntax (? rather than ?1) while they are bound via their position.
Further, we currently say that the dot-notation form is only required
to be supported for composite foreign keys and embedded primary keys.
It would be useful, though, for embeddables beyond primary keys as well
(then without the target entity, of course).
Finally, I believe, we ought to mention something about
createNativeQuery(String sqlString)
in case the query returns a result (i.e. is not a mere update or
delete).
> 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.
Sounds good to me. However, we ought to add which combinations are to
be supported at minimum and which are undefined resp. left to the JPA
provider.
Another gap we have, I think, is that we may dynamically create native
SQL queries, but have to hold the result set mappings in stock. It
would be good in my eyes if one could also create result set mappings
dynamically.
Best regards
Rainer
---
Rainer Schweigkoffer SAP AG Walldorf
Business Solution & Technology TD Core JS&I
Technology Development Dietmar-Hopp-Allee 16
Java Server Core D-69190 Walldorf
JEE Implementation Group phone: +49 6227 7 45305
Building 3, I.3.14 fax: +49 6227 7 821177
rainer.schweigkoffer_at_sap.com
Sitz der Gesellschaft/Registered Office: Walldorf, Germany
Vorstand/SAP Executive Board: Werner Brandt, Angelika Dammann,
Bill McDermott (Co-CEO), Gerhard Oswald, Vishal Sikka,
Jim Hagemann Snabe (Co-CEO)
Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory
Board: Hasso Plattner
Registergericht/Commercial Register Mannheim No HRB 350269
Diese E-Mail kann Betriebs- oder Geschaeftsgeheimnisse oder sonstige
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail
irrtuemlich erhalten haben, ist Ihnen eine Verwertung des Inhalts,
eine Vervielfaeltigung oder Weitergabe der E-Mail ausdruecklich
untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die
empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or
otherwise confidential information. If you have received this e-mail
in error, you are hereby notified that any review, copying, or
distribution of it is strictly prohibited. Please inform us
immediately and destroy the original transmittal. Thank you for your
cooperation.