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