Yes, that is how we need to proceed.
I'd like to hear from the experts on this group who represent JPA implementations:
How do you all handle this case?
If we have convergence on this, we should definitely clarify the spec. If not, I'm
afraid we are stuck with "undefined".
thanks,
Linda
On 12/11/2012 7:57 AM, michael keith wrote:
> Yeah, it's always a little tricky to catch the horse once it has left the barn. Someone ends up getting kicked ;-)
>
> If we want to update the spec to define the behavior for this case then we would need to poll the different impls to see
> what everybody does. If they all do the same thing then we could just specify that to be the "right thing". If not, we
> either go ahead and specify it anyway and the vendors who made the "wrong" choice have to figure out how to best help
> their customers, or we decide that the cost of specifying is not worth it.
>
> On 11/12/2012 10:43 AM, Gordon Yorke wrote:
>> An ISE would have been the correct choice when JPA was introduced but if we introduce this now I suspect a lot of
>> applications will stop working when someone upgrades. At this point we either leave it undefined or the spec should be
>> updated to cascade the merge to new objects.
>>
>> --Gordon
>> On 11/12/2012 9:46 AM, michael keith wrote:
>>> Hi Christian,
>>>
>>> While I think/hope the book describes the spec as completely as possible it probably shouldn't be taken as the
>>> definitive word ;-). However, I obviously agree with you that the spec is not well-defined for this case and needs to
>>> be clarified. My gut feeling is that it should probably end up as an ISE when the object gets flushed since there was
>>> no directive to merge the address, i.e. cascade merge was *not* specified.
>>>
>>> -Mike
>>>
>>> On 11/12/2012 3:37 AM, Christian von Kutzleben wrote:
>>>> Hi Gordon
>>>>
>>>> On Mon, Dec 10, 2012 at 9:21 PM, Gordon Yorke <gordon.yorke_at_oracle.com <mailto:gordon.yorke_at_oracle.com>> wrote:
>>>>
>>>> Hello Christian,
>>>> "m_p" would reference a new managed instance of the Address() that would be fully copied from the original
>>>> Address. The Address is fully copied because it is a practical way to get a managed version of the Address.
>>>> --Gordon
>>>>
>>>>
>>>> While researching more on this issue, I did also find the following statement in "Pro JPA 2", p. 161 "Merging
>>>> Detached Entities":
>>>>
>>>> "If the entity has a relationship to an object that has no persistent identity, the outcome of the merge operation
>>>> is undefined."
>>>>
>>>> So I agree, that what you described is a useful behavior (and that is what we do, if cascade-merge is enabled),
>>>> however this is not really defined in the spec,
>>>> and IMO needs clarification.
>>>>
>>>> Thank you!
>>>>
>>>> Christian
>>>>
>>>>
>>>> On 10/12/2012 8:56 AM, Christian von Kutzleben wrote:
>>>>> Dear group,
>>>>>
>>>>> What is supposed to happen in this scenario:
>>>>>
>>>>> @Entity
>>>>> class Person {
>>>>> //...
>>>>> Address address; //cascade-merge or cascade-all are not specified
>>>>> }
>>>>>
>>>>> @Entity
>>>>> class Address {
>>>>> //...
>>>>> }
>>>>>
>>>>> em.getTransaction().begin();
>>>>> Person p = new Person();
>>>>> em.persist(p);
>>>>> em.getTransaction().commit();
>>>>>
>>>>> em.getTransaction().begin();
>>>>> em.detach(p);
>>>>> p.setAddress(new Address());
>>>>> Person m_p = em.merge(p);
>>>>>
>>>>> //what does m_p's "address" field contain? Or should merge throw an exception right away?
>>>>>
>>>>>
>>>>> Thank you!
>>>>>
>>>>> Christian
>>>>>
>>>>> --
>>>>> Christian von Kutzleben
>>>>> Chief Engineer | Versant GmbH
>>>>> (T) +49 40 60990-0 <tel:%2B49%2040%2060990-0>
>>>>> (F) +49 40 60990-113 <tel:%2B49%2040%2060990-113>
>>>>> (E) cvkutzleben_at_versant.com <mailto:cromberg_at_versant.com>
>>>>> www.versant.com <http://www.versant.com> | www.db4o.com <http://www.db4o.com>
>>>>>
>>>>> --
>>>>> Versant
>>>>> GmbH is incorporated in Germany. Company registration number: HRB
>>>>> 54723, Amtsgericht Hamburg. Registered Office: Halenreie 42, 22359
>>>>> Hamburg, Germany. Geschäftsführer: Bernhard Wöbker, Volker John
>>>>>
>>>>> CONFIDENTIALITY
>>>>> NOTICE: This e-mail message, including any attachments, is for the sole
>>>>> use of the intended recipient(s) and may contain confidential or
>>>>> proprietary information. Any unauthorized review, use, disclosure or
>>>>> distribution is prohibited. If you are not the intended recipient,
>>>>> immediately contact the sender by reply e-mail and destroy all copies of
>>>>> the original message.
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Christian von Kutzleben
>>>> Chief Engineer | Versant GmbH
>>>> (T) +49 40 60990-0
>>>> (F) +49 40 60990-113
>>>> (E) cvkutzleben_at_versant.com <mailto:cromberg_at_versant.com>
>>>> www.versant.com <http://www.versant.com> | www.db4o.com <http://www.db4o.com>
>>>>
>>>> --
>>>> Versant
>>>> GmbH is incorporated in Germany. Company registration number: HRB
>>>> 54723, Amtsgericht Hamburg. Registered Office: Halenreie 42, 22359
>>>> Hamburg, Germany. Geschäftsführer: Bernhard Wöbker, Volker John
>>>>
>>>> CONFIDENTIALITY
>>>> NOTICE: This e-mail message, including any attachments, is for the sole
>>>> use of the intended recipient(s) and may contain confidential or
>>>> proprietary information. Any unauthorized review, use, disclosure or
>>>> distribution is prohibited. If you are not the intended recipient,
>>>> immediately contact the sender by reply e-mail and destroy all copies of
>>>> the original message.
>>>>
>>