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
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 marc.logem...@gmail.com
wrote:
Rick,
thanks for pointing out. I will check this too. But regardless of the
outcome, i
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();
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
. 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
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.
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 marc.logem...@gmail.com
wrote:
Kevin,
thanks
