[jsr338-experts] Re: improved SQL result set mapping
This language is fine.
--Gordon
Linda DeMichiel wrote:
>
>
> 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.
>>>>
>>>>
>