Hi Rainer, all,
On 4/15/2011 5:29 AM, Rainer Kwesi Schweigkoffer wrote:
> 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.
>
Thanks!
>> 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.
>
Well, the obvious options here are:
(1) undefined;
(2) they are ignored;
(3) error.
I prefer (1) or (2). Right now the spec silently assumes (1) in my view.
Opinions, please....
> 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.
>
Sure. I've added your suggested comment to section 3.8.12.
> 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).
>
Yes. Already done :-)
> 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).
>
This is a good point. How about the following:
If the query is not an update or delete query, query execution will result
in each row of the SQL result being returned as a result of type Object[]
(or as a result of type Object if there is only one column in the select
list.) Column values are returned in the order of their appearance in
the select list and default JDBC type mappings are applied.
>> 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.
>
Where would you draw the line here?
> 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.
>
I agree, and have been mulling over this issue myself. I see it as
lower priority though, and I think I would prefer to defer it till
later in the JSR pending available time.
best regards,
-Linda
> 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.
>
>