Hello all,
>> 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....
(2) Ignored
>> 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.
What are the details of this comment. We should not disallow actual
positional parameters here if a provider wants to support it.
--Gordon
Linda DeMichiel wrote:
> 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.
>>
>>