You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Marc Logemann <ma...@gmail.com> on 2014/06/02 14:48:33 UTC
behavior change from 2.1.0 to 2.2.0 on persist
Hey,
we recently switched to 2.2.0 (cant go higher because we use Java8) and we
found a change in behavior.
Asumme we created a new Entity which looks like this:
Person.java
------------------
int oid
String name
CustomerType adress
we created the object like so:
Person p = new Person();
p.setName("foo);
CustomerType ct = new CustomerType();
ct.setOid(1); // THIS OID already exists and we want to map the existant
object to Person
p.setCustomerType(ct);
persist(p);
=====
In 2.1.0 OpemJPA knew that there is a CustomerType in the DB with this oid
and loads it automaticly and the child object is "managed". With 2.2.0 this
is no longer the case and we get a "Unmanaged bla bla bla Exception". We
relied on that behavior heavily and the rewrite is a tough for all areas.
Is there some kind of config setting where i can set the "old behavior". Or
was this old behavior a bug? ;-)
Thanks for hints.
Marc
Re: behavior change from 2.1.0 to 2.2.0 on persist
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Marc,
I do like Boblitz's suggestion of using getReference. It's a little less
weight than a full find() operation.
Kevin
On Tue, Jun 3, 2014 at 9:07 AM, Marc Logemann <ma...@gmail.com>
wrote:
> Rick,
>
> thanks for pointing out. I will check this too. But regardless of the
> outcome, i think we will recode the stuff which is affected, because its
> better coding style to load related entities and point the managed entities
> to the desired other entities. This way people know whats going on without
> relying on any ORM magic.
>
>
> 2014-06-02 18:26 GMT+02:00 Rick Curtis <cu...@gmail.com>:
>
> > Marc --
> >
> > I'm thinking that there was a change in cascade persist behavior that you
> > might be running into.
> >
> >
> >
> http://openjpa.apache.org/builds/2.2.2/apache-openjpa/docs/jpa_2.2.html#jpa_2.2_cascadePersist
> >
> >
> > On Mon, Jun 2, 2014 at 9:53 AM, Marc Logemann <ma...@gmail.com>
> > wrote:
> >
> > > Kevin,
> > >
> > > thanks for fast feedback. To your questions:
> > >
> > > 1) of course we could do the em.find() and do it the way it should be
> > done
> > > ;-)
> > >
> > > 2) no, we have not tried using em.merge(), this would be an option we
> > could
> > > check out.
> > >
> > > And yes. WE dont want to persist the CustomerType since its already
> > there.
> > > We just want to create the relationship.
> > >
> > > Thanks again. And now we will happily wait for Java8 Support in your
> > > bytecode enhancer so that we could upgrade to latest Version of
> OpenJPA
> > > instead of being stuck to 2.2.0 ;-)
> > >
> > > Marc
> > >
> > >
> > > 2014-06-02 16:11 GMT+02:00 Kevin Sutter <kw...@gmail.com>:
> > >
> > > > Hi Marc,
> > > > Sorry for the troubles. Technically, it looks like you were lucky
> and
> > > > coding to a bug in the OpenJPA code. Since you just created this
> > > > CustomerType, we have to assume that it's unmanaged. And, we can't
> > > > automatically cascade the persist operation to this unmanaged entity.
> > > And,
> > > > in your particular case, we wouldn't want to persist this entity
> since
> > it
> > > > already exists.
> > > >
> > > > Just to be clear, you don't want this CustomerType to be persisted,
> > > right?
> > > > You are just creating this to satisfy the relationship from Person,
> > > right?
> > > >
> > > > A couple of ideas come to mind...
> > > >
> > > > 1) Can you do an em.find() operation on your CustomerType? I
> realize
> > > this
> > > > is an extra SQL, but then this CustomerType would be managed and
> > satisfy
> > > > the requirement.
> > > >
> > > > 2) Have you tried using em.merge(p) instead of em.persist(p)? The
> > merge
> > > > should do either the update or insert based on the state of the
> object.
> > > > When we get to the CustomerType, we might have to do the extra SQL to
> > > > determine if it exists already, but then we should be okay. This
> JIRA
> > > [1]
> > > > from the 2.2.0 Release Notes [2] makes me think this might work...
> > > >
> > > > Maybe somebody else has some ideas on how to get around this
> scenario.
> > > >
> > > > [1] https://issues.apache.org/jira/browse/OPENJPA-1896
> > > > [2]
> > > >
> > http://openjpa.apache.org/builds/2.2.0/apache-openjpa/RELEASE-NOTES.html
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Jun 2, 2014 at 7:48 AM, Marc Logemann <
> marc.logemann@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hey,
> > > > >
> > > > > we recently switched to 2.2.0 (cant go higher because we use Java8)
> > and
> > > > we
> > > > > found a change in behavior.
> > > > >
> > > > > Asumme we created a new Entity which looks like this:
> > > > >
> > > > > Person.java
> > > > > ------------------
> > > > > int oid
> > > > > String name
> > > > > CustomerType adress
> > > > >
> > > > >
> > > > > we created the object like so:
> > > > >
> > > > > Person p = new Person();
> > > > > p.setName("foo);
> > > > >
> > > > > CustomerType ct = new CustomerType();
> > > > > ct.setOid(1); // THIS OID already exists and we want to map the
> > > existant
> > > > > object to Person
> > > > >
> > > > > p.setCustomerType(ct);
> > > > >
> > > > > persist(p);
> > > > >
> > > > >
> > > > > =====
> > > > >
> > > > > In 2.1.0 OpemJPA knew that there is a CustomerType in the DB with
> > this
> > > > oid
> > > > > and loads it automaticly and the child object is "managed". With
> > 2.2.0
> > > > this
> > > > > is no longer the case and we get a "Unmanaged bla bla bla
> Exception".
> > > We
> > > > > relied on that behavior heavily and the rewrite is a tough for all
> > > areas.
> > > > > Is there some kind of config setting where i can set the "old
> > > behavior".
> > > > Or
> > > > > was this old behavior a bug? ;-)
> > > > >
> > > > > Thanks for hints.
> > > > >
> > > > > Marc
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > *Rick Curtis*
> >
>
Re: behavior change from 2.1.0 to 2.2.0 on persist
Posted by Marc Logemann <ma...@gmail.com>.
Rick,
thanks for pointing out. I will check this too. But regardless of the
outcome, i think we will recode the stuff which is affected, because its
better coding style to load related entities and point the managed entities
to the desired other entities. This way people know whats going on without
relying on any ORM magic.
2014-06-02 18:26 GMT+02:00 Rick Curtis <cu...@gmail.com>:
> Marc --
>
> I'm thinking that there was a change in cascade persist behavior that you
> might be running into.
>
>
> http://openjpa.apache.org/builds/2.2.2/apache-openjpa/docs/jpa_2.2.html#jpa_2.2_cascadePersist
>
>
> On Mon, Jun 2, 2014 at 9:53 AM, Marc Logemann <ma...@gmail.com>
> wrote:
>
> > Kevin,
> >
> > thanks for fast feedback. To your questions:
> >
> > 1) of course we could do the em.find() and do it the way it should be
> done
> > ;-)
> >
> > 2) no, we have not tried using em.merge(), this would be an option we
> could
> > check out.
> >
> > And yes. WE dont want to persist the CustomerType since its already
> there.
> > We just want to create the relationship.
> >
> > Thanks again. And now we will happily wait for Java8 Support in your
> > bytecode enhancer so that we could upgrade to latest Version of OpenJPA
> > instead of being stuck to 2.2.0 ;-)
> >
> > Marc
> >
> >
> > 2014-06-02 16:11 GMT+02:00 Kevin Sutter <kw...@gmail.com>:
> >
> > > Hi Marc,
> > > Sorry for the troubles. Technically, it looks like you were lucky and
> > > coding to a bug in the OpenJPA code. Since you just created this
> > > CustomerType, we have to assume that it's unmanaged. And, we can't
> > > automatically cascade the persist operation to this unmanaged entity.
> > And,
> > > in your particular case, we wouldn't want to persist this entity since
> it
> > > already exists.
> > >
> > > Just to be clear, you don't want this CustomerType to be persisted,
> > right?
> > > You are just creating this to satisfy the relationship from Person,
> > right?
> > >
> > > A couple of ideas come to mind...
> > >
> > > 1) Can you do an em.find() operation on your CustomerType? I realize
> > this
> > > is an extra SQL, but then this CustomerType would be managed and
> satisfy
> > > the requirement.
> > >
> > > 2) Have you tried using em.merge(p) instead of em.persist(p)? The
> merge
> > > should do either the update or insert based on the state of the object.
> > > When we get to the CustomerType, we might have to do the extra SQL to
> > > determine if it exists already, but then we should be okay. This JIRA
> > [1]
> > > from the 2.2.0 Release Notes [2] makes me think this might work...
> > >
> > > Maybe somebody else has some ideas on how to get around this scenario.
> > >
> > > [1] https://issues.apache.org/jira/browse/OPENJPA-1896
> > > [2]
> > >
> http://openjpa.apache.org/builds/2.2.0/apache-openjpa/RELEASE-NOTES.html
> > >
> > >
> > >
> > >
> > > On Mon, Jun 2, 2014 at 7:48 AM, Marc Logemann <marc.logemann@gmail.com
> >
> > > wrote:
> > >
> > > > Hey,
> > > >
> > > > we recently switched to 2.2.0 (cant go higher because we use Java8)
> and
> > > we
> > > > found a change in behavior.
> > > >
> > > > Asumme we created a new Entity which looks like this:
> > > >
> > > > Person.java
> > > > ------------------
> > > > int oid
> > > > String name
> > > > CustomerType adress
> > > >
> > > >
> > > > we created the object like so:
> > > >
> > > > Person p = new Person();
> > > > p.setName("foo);
> > > >
> > > > CustomerType ct = new CustomerType();
> > > > ct.setOid(1); // THIS OID already exists and we want to map the
> > existant
> > > > object to Person
> > > >
> > > > p.setCustomerType(ct);
> > > >
> > > > persist(p);
> > > >
> > > >
> > > > =====
> > > >
> > > > In 2.1.0 OpemJPA knew that there is a CustomerType in the DB with
> this
> > > oid
> > > > and loads it automaticly and the child object is "managed". With
> 2.2.0
> > > this
> > > > is no longer the case and we get a "Unmanaged bla bla bla Exception".
> > We
> > > > relied on that behavior heavily and the rewrite is a tough for all
> > areas.
> > > > Is there some kind of config setting where i can set the "old
> > behavior".
> > > Or
> > > > was this old behavior a bug? ;-)
> > > >
> > > > Thanks for hints.
> > > >
> > > > Marc
> > > >
> > >
> >
>
>
>
> --
> *Rick Curtis*
>
Re: behavior change from 2.1.0 to 2.2.0 on persist
Posted by Rick Curtis <cu...@gmail.com>.
Marc --
I'm thinking that there was a change in cascade persist behavior that you
might be running into.
http://openjpa.apache.org/builds/2.2.2/apache-openjpa/docs/jpa_2.2.html#jpa_2.2_cascadePersist
On Mon, Jun 2, 2014 at 9:53 AM, Marc Logemann <ma...@gmail.com>
wrote:
> Kevin,
>
> thanks for fast feedback. To your questions:
>
> 1) of course we could do the em.find() and do it the way it should be done
> ;-)
>
> 2) no, we have not tried using em.merge(), this would be an option we could
> check out.
>
> And yes. WE dont want to persist the CustomerType since its already there.
> We just want to create the relationship.
>
> Thanks again. And now we will happily wait for Java8 Support in your
> bytecode enhancer so that we could upgrade to latest Version of OpenJPA
> instead of being stuck to 2.2.0 ;-)
>
> Marc
>
>
> 2014-06-02 16:11 GMT+02:00 Kevin Sutter <kw...@gmail.com>:
>
> > Hi Marc,
> > Sorry for the troubles. Technically, it looks like you were lucky and
> > coding to a bug in the OpenJPA code. Since you just created this
> > CustomerType, we have to assume that it's unmanaged. And, we can't
> > automatically cascade the persist operation to this unmanaged entity.
> And,
> > in your particular case, we wouldn't want to persist this entity since it
> > already exists.
> >
> > Just to be clear, you don't want this CustomerType to be persisted,
> right?
> > You are just creating this to satisfy the relationship from Person,
> right?
> >
> > A couple of ideas come to mind...
> >
> > 1) Can you do an em.find() operation on your CustomerType? I realize
> this
> > is an extra SQL, but then this CustomerType would be managed and satisfy
> > the requirement.
> >
> > 2) Have you tried using em.merge(p) instead of em.persist(p)? The merge
> > should do either the update or insert based on the state of the object.
> > When we get to the CustomerType, we might have to do the extra SQL to
> > determine if it exists already, but then we should be okay. This JIRA
> [1]
> > from the 2.2.0 Release Notes [2] makes me think this might work...
> >
> > Maybe somebody else has some ideas on how to get around this scenario.
> >
> > [1] https://issues.apache.org/jira/browse/OPENJPA-1896
> > [2]
> > http://openjpa.apache.org/builds/2.2.0/apache-openjpa/RELEASE-NOTES.html
> >
> >
> >
> >
> > On Mon, Jun 2, 2014 at 7:48 AM, Marc Logemann <ma...@gmail.com>
> > wrote:
> >
> > > Hey,
> > >
> > > we recently switched to 2.2.0 (cant go higher because we use Java8) and
> > we
> > > found a change in behavior.
> > >
> > > Asumme we created a new Entity which looks like this:
> > >
> > > Person.java
> > > ------------------
> > > int oid
> > > String name
> > > CustomerType adress
> > >
> > >
> > > we created the object like so:
> > >
> > > Person p = new Person();
> > > p.setName("foo);
> > >
> > > CustomerType ct = new CustomerType();
> > > ct.setOid(1); // THIS OID already exists and we want to map the
> existant
> > > object to Person
> > >
> > > p.setCustomerType(ct);
> > >
> > > persist(p);
> > >
> > >
> > > =====
> > >
> > > In 2.1.0 OpemJPA knew that there is a CustomerType in the DB with this
> > oid
> > > and loads it automaticly and the child object is "managed". With 2.2.0
> > this
> > > is no longer the case and we get a "Unmanaged bla bla bla Exception".
> We
> > > relied on that behavior heavily and the rewrite is a tough for all
> areas.
> > > Is there some kind of config setting where i can set the "old
> behavior".
> > Or
> > > was this old behavior a bug? ;-)
> > >
> > > Thanks for hints.
> > >
> > > Marc
> > >
> >
>
--
*Rick Curtis*
Re: behavior change from 2.1.0 to 2.2.0 on persist
Posted by Marc Logemann <ma...@gmail.com>.
Kevin,
thanks for fast feedback. To your questions:
1) of course we could do the em.find() and do it the way it should be done
;-)
2) no, we have not tried using em.merge(), this would be an option we could
check out.
And yes. WE dont want to persist the CustomerType since its already there.
We just want to create the relationship.
Thanks again. And now we will happily wait for Java8 Support in your
bytecode enhancer so that we could upgrade to latest Version of OpenJPA
instead of being stuck to 2.2.0 ;-)
Marc
2014-06-02 16:11 GMT+02:00 Kevin Sutter <kw...@gmail.com>:
> Hi Marc,
> Sorry for the troubles. Technically, it looks like you were lucky and
> coding to a bug in the OpenJPA code. Since you just created this
> CustomerType, we have to assume that it's unmanaged. And, we can't
> automatically cascade the persist operation to this unmanaged entity. And,
> in your particular case, we wouldn't want to persist this entity since it
> already exists.
>
> Just to be clear, you don't want this CustomerType to be persisted, right?
> You are just creating this to satisfy the relationship from Person, right?
>
> A couple of ideas come to mind...
>
> 1) Can you do an em.find() operation on your CustomerType? I realize this
> is an extra SQL, but then this CustomerType would be managed and satisfy
> the requirement.
>
> 2) Have you tried using em.merge(p) instead of em.persist(p)? The merge
> should do either the update or insert based on the state of the object.
> When we get to the CustomerType, we might have to do the extra SQL to
> determine if it exists already, but then we should be okay. This JIRA [1]
> from the 2.2.0 Release Notes [2] makes me think this might work...
>
> Maybe somebody else has some ideas on how to get around this scenario.
>
> [1] https://issues.apache.org/jira/browse/OPENJPA-1896
> [2]
> http://openjpa.apache.org/builds/2.2.0/apache-openjpa/RELEASE-NOTES.html
>
>
>
>
> On Mon, Jun 2, 2014 at 7:48 AM, Marc Logemann <ma...@gmail.com>
> wrote:
>
> > Hey,
> >
> > we recently switched to 2.2.0 (cant go higher because we use Java8) and
> we
> > found a change in behavior.
> >
> > Asumme we created a new Entity which looks like this:
> >
> > Person.java
> > ------------------
> > int oid
> > String name
> > CustomerType adress
> >
> >
> > we created the object like so:
> >
> > Person p = new Person();
> > p.setName("foo);
> >
> > CustomerType ct = new CustomerType();
> > ct.setOid(1); // THIS OID already exists and we want to map the existant
> > object to Person
> >
> > p.setCustomerType(ct);
> >
> > persist(p);
> >
> >
> > =====
> >
> > In 2.1.0 OpemJPA knew that there is a CustomerType in the DB with this
> oid
> > and loads it automaticly and the child object is "managed". With 2.2.0
> this
> > is no longer the case and we get a "Unmanaged bla bla bla Exception". We
> > relied on that behavior heavily and the rewrite is a tough for all areas.
> > Is there some kind of config setting where i can set the "old behavior".
> Or
> > was this old behavior a bug? ;-)
> >
> > Thanks for hints.
> >
> > Marc
> >
>
AW: behavior change from 2.1.0 to 2.2.0 on persist
Posted by Boblitz John <jo...@bertschi.com>.
Hello,
We solved this by using the getReference() method.
Something like
Person p = new Person();
p.setName("foo);
p.setCustomerType(em.getReference(CustomerType.class, 1);
persist(p);
John
-----Ursprüngliche Nachricht-----
Von: Kevin Sutter [mailto:kwsutter@gmail.com]
Gesendet: Montag, 2. Juni 2014 16:11
An: users@openjpa.apache.org
Betreff: Re: behavior change from 2.1.0 to 2.2.0 on persist
Hi Marc,
Sorry for the troubles. Technically, it looks like you were lucky and coding to a bug in the OpenJPA code. Since you just created this CustomerType, we have to assume that it's unmanaged. And, we can't automatically cascade the persist operation to this unmanaged entity. And, in your particular case, we wouldn't want to persist this entity since it already exists.
Just to be clear, you don't want this CustomerType to be persisted, right?
You are just creating this to satisfy the relationship from Person, right?
A couple of ideas come to mind...
1) Can you do an em.find() operation on your CustomerType? I realize this is an extra SQL, but then this CustomerType would be managed and satisfy the requirement.
2) Have you tried using em.merge(p) instead of em.persist(p)? The merge should do either the update or insert based on the state of the object.
When we get to the CustomerType, we might have to do the extra SQL to determine if it exists already, but then we should be okay. This JIRA [1] from the 2.2.0 Release Notes [2] makes me think this might work...
Maybe somebody else has some ideas on how to get around this scenario.
[1] https://issues.apache.org/jira/browse/OPENJPA-1896
[2]
http://openjpa.apache.org/builds/2.2.0/apache-openjpa/RELEASE-NOTES.html
On Mon, Jun 2, 2014 at 7:48 AM, Marc Logemann <ma...@gmail.com>
wrote:
> Hey,
>
> we recently switched to 2.2.0 (cant go higher because we use Java8)
> and we found a change in behavior.
>
> Asumme we created a new Entity which looks like this:
>
> Person.java
> ------------------
> int oid
> String name
> CustomerType adress
>
>
> we created the object like so:
>
> Person p = new Person();
> p.setName("foo);
>
> CustomerType ct = new CustomerType();
> ct.setOid(1); // THIS OID already exists and we want to map the
> existant object to Person
>
> p.setCustomerType(ct);
>
> persist(p);
>
>
> =====
>
> In 2.1.0 OpemJPA knew that there is a CustomerType in the DB with this
> oid and loads it automaticly and the child object is "managed". With
> 2.2.0 this is no longer the case and we get a "Unmanaged bla bla bla
> Exception". We relied on that behavior heavily and the rewrite is a tough for all areas.
> Is there some kind of config setting where i can set the "old
> behavior". Or was this old behavior a bug? ;-)
>
> Thanks for hints.
>
> Marc
>
Re: behavior change from 2.1.0 to 2.2.0 on persist
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Marc,
Sorry for the troubles. Technically, it looks like you were lucky and
coding to a bug in the OpenJPA code. Since you just created this
CustomerType, we have to assume that it's unmanaged. And, we can't
automatically cascade the persist operation to this unmanaged entity. And,
in your particular case, we wouldn't want to persist this entity since it
already exists.
Just to be clear, you don't want this CustomerType to be persisted, right?
You are just creating this to satisfy the relationship from Person, right?
A couple of ideas come to mind...
1) Can you do an em.find() operation on your CustomerType? I realize this
is an extra SQL, but then this CustomerType would be managed and satisfy
the requirement.
2) Have you tried using em.merge(p) instead of em.persist(p)? The merge
should do either the update or insert based on the state of the object.
When we get to the CustomerType, we might have to do the extra SQL to
determine if it exists already, but then we should be okay. This JIRA [1]
from the 2.2.0 Release Notes [2] makes me think this might work...
Maybe somebody else has some ideas on how to get around this scenario.
[1] https://issues.apache.org/jira/browse/OPENJPA-1896
[2]
http://openjpa.apache.org/builds/2.2.0/apache-openjpa/RELEASE-NOTES.html
On Mon, Jun 2, 2014 at 7:48 AM, Marc Logemann <ma...@gmail.com>
wrote:
> Hey,
>
> we recently switched to 2.2.0 (cant go higher because we use Java8) and we
> found a change in behavior.
>
> Asumme we created a new Entity which looks like this:
>
> Person.java
> ------------------
> int oid
> String name
> CustomerType adress
>
>
> we created the object like so:
>
> Person p = new Person();
> p.setName("foo);
>
> CustomerType ct = new CustomerType();
> ct.setOid(1); // THIS OID already exists and we want to map the existant
> object to Person
>
> p.setCustomerType(ct);
>
> persist(p);
>
>
> =====
>
> In 2.1.0 OpemJPA knew that there is a CustomerType in the DB with this oid
> and loads it automaticly and the child object is "managed". With 2.2.0 this
> is no longer the case and we get a "Unmanaged bla bla bla Exception". We
> relied on that behavior heavily and the rewrite is a tough for all areas.
> Is there some kind of config setting where i can set the "old behavior". Or
> was this old behavior a bug? ;-)
>
> Thanks for hints.
>
> Marc
>