Yes, thanks -- that was the part of Rainer's initial message that
I asked for clarification on.
So, the issue becomes whether we want to support that case as well,
or draw the line there.
-Linda
On 4/26/2011 12:03 PM, Gordon Yorke wrote:
> If an Entity's constructor is used then the resulting Entity instances
> are in the "new" state. However, Rainer is suggesting Entity results
> could be used as Constructor arguments and in that case the Entities
> would be managed. (Page 178, second paragraph).
> --Gordon
>
> Linda DeMichiel wrote:
>> JPQL specifies them to be in the "new" state.
>>
>> On 4/26/2011 11:49 AM, Gordon Yorke wrote:
>>> Did you mean to say -> I think it makes sense to have this mirror the
>>> semantics of constructors in a JPQL select list-- i.e., the resulting
>>> entities would be _managed_.
>>> --Gordon
>>>
>>> Linda DeMichiel wrote:
>>>> Hi Rainer, all,
>>>>
>>>> Please excuse the delay in response as I have been travelling.
>>>>
>>>> Yes, I think it is reasonable to extend ConstructorResult to entities.
>>>> If we do, I think it makes sense to have this mirror the semantics of
>>>> constructors in a JPQL select list-- i.e., the resulting entities
>>>> would be unmanaged.
>>>>
>>>> I'm afraid I don't understand your comment below about the ordering
>>>> of constructor parameters though. Could you explain further?
>>>>
>>>> thanks,
>>>>
>>>> -Linda
>>>>
>>>>
>>>> On 4/20/2011 1:03 AM, Rainer Kwesi Schweigkoffer wrote:
>>>>> Hi Linda, all,
>>>>>
>>>>> Linda DeMichiel, am 19 Apr 2011 hast Du um 11:22 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.
>>>>>
>>>>> Actually, my point here is that constructor expressions in JPQL
>>>>> allow for entities as arguments, and I would find it quite helpful
>>>>> for users if similar constructs would be defined with as similar
>>>>> functional range as possible throughout the spec. Users already
>>>>> have to face intricacies like e.g.
>>>>>
>>>>> Native SQL queries -> positional parameters
>>>>> Stored procedures -> positional and named parameters
>>>>> JPQL queries -> positional and named parameters
>>>>> Criteria queries -> named and unnamed parameters
>>>>>
>>>>> Wouldn't want to open up another one here as well...
>>>>>
>>>>> 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.
>>>>>
>>>>>