Hi Rainer, all
Some answers embedded below....
thanks,
-Linda
On 4/18/2011 6:02 AM, Rainer Kwesi Schweigkoffer wrote:
> Hi Linda, all,
>
> Linda DeMichiel, am 15 Apr 2011 hast Du um 13:10 zum Thema "[jsr338-experts] Re: improved SQL result set mapp" 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.
>
>
> Any opinion on the above ?
I think I would prefer to defer the issue pending any requests.
>
>
>> 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.
>
>
> Linda, what do you precisely mean by "default JDBC type mappings" ?
>
The mappings defined in appendix B of the JDBC spec.
> Would you want to you refer to the recommended getXXX methods for
> retrieval of JDBC types as per the JDBC API tutorial and reference ? Or
> would you rather like to denote provider specific mapping for
> ColumnResults (without given Java return type) ? Alternatively, it
> could make sense to say getObject() was to be called here.
>
>
>>>> 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?
>
>
> Well, we could say something like "if for the specified Java type a
> getter method exists on java.sql.ResultSet that method is called; else
> the behaviour is implementation-defined".
>
> 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.
>
>