We cannot require an exception immediately on the call to merge since
the spec allows the cascades (or lack thereof) to be processed at flush
time. That is what happens in Hibernate. You'd end up here with a
javax.persistence.RollbackException (caused by an IllegalStateException
due to the transient, non-cascaded association).
On Wed 12 Dec 2012 02:22:26 AM CST, Christian von Kutzleben wrote:
> Hi Linda,
>
> For Versant/JPA we are open to change our behavior for this case.
>
> Christian
>
> On Tue, Dec 11, 2012 at 6:43 PM, Linda DeMichiel
> <linda.demichiel_at_oracle.com <mailto:linda.demichiel_at_oracle.com>> wrote:
>
> 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>
> <mailto: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>
> <tel:%2B49%2040%2060990-0>
> (F) +49 40 60990-113
> <tel:%2B49%2040%2060990-113>
> <tel:%2B49%2040%2060990-113>
> (E) cvkutzleben_at_versant.com
> <mailto:cvkutzleben_at_versant.com>
> <mailto:cromberg_at_versant.com
> <mailto:cromberg_at_versant.com>>
> www.versant.com <http://www.versant.com>
> <http://www.versant.com> | www.db4o.com
> <http://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 <tel:%2B49%2040%2060990-0>
> (F) +49 40 60990-113 <tel:%2B49%2040%2060990-113>
> (E) cvkutzleben_at_versant.com
> <mailto:cvkutzleben_at_versant.com>
> <mailto:cromberg_at_versant.com
> <mailto:cromberg_at_versant.com>>
> www.versant.com <http://www.versant.com>
> <http://www.versant.com> | www.db4o.com
> <http://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.
>