On 4/18/2011 7:46 AM, Gordon Yorke wrote:
> 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.
>
The draft for this section is currently as follows:
3.8.13 Positional Parameters
Only positional parameter binding and positional access to result items may be portably
used for native queries, except for stored procedure queries for which named parameters
have been defined. When binding the values of positional parameters, the numbering
starts as "1". It is assumed that for native queries the parameters themselves use
the SQL syntax (i.e., "?", rather than "?1".
The use of positional parameters is not supported for criteria queries.
IMO this allows latitude for providers who want to support an alternative syntax.
If you would like me to add language like "Providers may support additional syntax
for positional parameters, however use of an alternative syntax will not be portable",
that's ok by me.
-Linda
> --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.
>>>
>>>