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.
>>>
>>>