>
> 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".
There is already a set of prescribed types that can be used with Entity
@Basic attributes and we should use that list. Any other types would be
left as provider dependant. Making the provider call the typed getter
methods on the driver may have unintentional implications (performance,
lack of driver support, other side-effects).
--Gordon
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 ?
>
>
>
>> 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" ?
>
> 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.
>
>
>