Sorry for replying to an old topic, but you are right. At the moment I also want to copy entities and I am running into the same problem with my serialize deserialize trick, even after setting id and version to null OpenJPA still thinks it is an existing entity, even though I don't use a detached state field and no detached state manager; OpenJPA still adds the pcVersionInit field and sets it to true.
I guess a copy constructor is the safest bet, or otherwise set it to false with Reflection which can get a bit tricky (I had multiple pcVersionInit fields in one entity, probably in superclasses or something). Henno -----Oorspronkelijk bericht----- Van: Mark Struberg [mailto:[email protected]] Verzonden: vrijdag 14 januari 2011 18:15 Aan: [email protected] Onderwerp: Re: How to persist duplicate of an entity? btw, I found the default difference between a 'normally' detached entity and a serialisation/deserialisation detached entity pretty heavy. This introduced several errors which were pretty hard to explain to an average-joe developer. An application by default might behave completely different if you run it on a local tomcat or in a cluster environment (with sessions getting replicated via memcached all the times). Another example would be using the JSF @ViewScoped (JSF2 ViewMap must get serialized with every request) vs e.g. @RequestScoped. Because of that I'm currently in the process of switching to openjpa.DetachState=loaded(DetachedStateField=true) which hopefully will remove this obscurities. As far as I understand, this will also restore the _pcVersionInit and others, isn't? LieGrue, strub --- On Fri, 1/14/11, Rick Curtis <[email protected]> wrote: > From: Rick Curtis <[email protected]> > Subject: Re: How to persist duplicate of an entity? > To: [email protected] > Date: Friday, January 14, 2011, 5:03 PM > > OpenJPA considers the entity a > detached object even if you reset the Id > and version field. > In the absence of some sort of StateManager (Impl or > Detached) we use the > version field and another enhancer added field to detect > whether an Entity > is new or detached. > > > Might be a bit too stringent and the error message is > misleading (read > wrong). > Misleading, probably. > > The problem is that we key off the fact that the version > field was set. @See > _pcVersionInit in an enhanced Entity. This field is used to > differentiate > between a uninitialized primitive and a primitive that was > actually set to > the default value (ie: setting an int version to zero). One > way to get > around this would be to serialize/deserialize an Entity > after setting the > version field. Or you could use reflection to set > _pcVersionInit to > false.... but neither options are good ones. > > This is a use case is one that wasn't considered when this > code was written. > > > Thanks, > Rick.. > > On Fri, Jan 14, 2011 at 10:47 AM, Mark Struberg <[email protected]> > wrote: > > > I think this is perfectly ok with managed entities. It > might of course work > > with detached ones. Just remember that JPA is a ORM > mapper. Thus a primary > > key usually must not get changed. > > > > LieGrue, > > strub > > > > --- On Fri, 1/14/11, Kevin Sutter <[email protected]> > wrote: > > > > > From: Kevin Sutter <[email protected]> > > > Subject: Re: How to persist duplicate of an > entity? > > > To: [email protected] > > > Date: Friday, January 14, 2011, 4:20 PM > > > You are right, Jerry... It > > > looks like some recent changes to detect version > > > field updates are preventing this type of > processing. > > > Even though the > > > exception text makes it sound like we should be > able to get > > > around it... > > > > > > <openjpa-2.2.0-SNAPSHOT-r422266:1057901M > nonfatal store > > > error> > > > > org.apache.openjpa.persistence.EntityExistsException: > > > Attempt to persist > > > detached object > "simple.model.Person@105a105a". If > > > this is a new instance, > > > make sure any version and/or auto-generated > primary key > > > fields are > > > null/default when persisting. > > > FailedObject: simple.model.Person@105a105a > > > > > > I tried with and without a version field. > And, I > > > tried with both primitive > > > int and Integer version fields. No matter > what I > > > tried, I hit this > > > exception either on the first or second commit of > the > > > Person instance. Even > > > though I am not using auto-generated keys and my > version > > > field is either > > > nulled out or zeroed out. > > > > > > Maybe this check is too stringent? > > > > > > Anyway, it sounds like this short cut won't work > for > > > Ognjen. Thanks for > > > keeping me honest. > > > > > > Kevin > > > > > > > > > On Fri, Jan 14, 2011 at 9:25 AM, No1UNo <[email protected]> > > > wrote: > > > > > > > > > > > In a recent application, I was forced to > resort to a > > > copy constructor to > > > > explicitly make a copy of the object. > I tried to > > > reuse and re-persist an > > > > entity after making a few changes, but any > attempt to > > > change the value of > > > > the @Id was blocked by OpenJPA. > > > > > > > > On Jan 14, 2011, at 10:19 AM, Kevin Sutter > [via > > > OpenJPA] wrote: > > > > > > > > > There are so many variables that can > come into > > > play with a scenario like > > > > > this... > > > > > > > > > > If you are only looking to populate the > database > > > and you don't care about > > > > > the actual Entity objects, then you > could just > > > populate a single Entity > > > > > instance. In a loop, persist and > commit > > > this entity, update the key and > > > > > repeat. If you are using a > Version field, > > > then you'll also have to reset > > > > > that each time. > > > > > > > > > > It all depends on the end game... > :-) > > > > > > > > > > Kevin > > > > > > > > > > On Fri, Jan 14, 2011 at 8:52 AM, Henno > Vermeulen > > > <[hidden email]>wrote: > > > > > > > > > > > The easiest way that I found to > create a > > > deep clone of an object graph > > > > is > > > > > > to use apache commons > collections. > > > > > > > > > > SerializationUtils.deserialize(SerializationUtils.serialize(object)). > > > > > > > > > > > > Can of course also be used for a > simple > > > entity without relations. In > > > > anyway > > > > > > you have to watch out that you > still set all > > > primary keys to null. (May > > > > also > > > > > > not be most performant way.) > > > > > > > > > > > > Regards, > > > > > > Henno Vermeulen > > > > > > Huize Molenaar > > > > > > > > > > > > -----Oorspronkelijk bericht----- > > > > > > Van: Ognjen Blagojevic > [mailto:[hidden > > > email]] > > > > > > Verzonden: vrijdag 14 januari 2011 > 15:12 > > > > > > Aan: [hidden email] > > > > > > Onderwerp: How to persist > duplicate of an > > > entity? > > > > > > > > > > > > Hi, > > > > > > > > > > > > Is there an easy way to create > duplicate of > > > an entity? > > > > > > > > > > > > I want to read entity from the DB, > and then > > > persist (almost) identical > > > > > > copy. Every field should be the > same, except > > > primary key. > > > > > > > > > > > > I know I could probably use > > > BeanUtils.copyProperties, but is there > > > > > > OpenJPA preffered way to do the > > > duplication? > > > > > > > > > > > > Regards, > > > > > > Ognjen > > > > > > > > >
