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