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 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 <kwsut...@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.logem...@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*
