openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Curtis <curti...@gmail.com>
Subject Re: behavior change from 2.1.0 to 2.2.0 on persist
Date Mon, 02 Jun 2014 16:26:01 GMT
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.logemann@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 <kwsutter@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*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message