openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henno Vermeulen <he...@huizemolenaar.nl>
Subject RE: How to persist duplicate of an entity?
Date Mon, 21 Feb 2011 12:00:21 GMT
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:struberg@yahoo.de] 
Verzonden: vrijdag 14 januari 2011 18:15
Aan: users@openjpa.apache.org
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 <curtisr7@gmail.com> wrote:

> From: Rick Curtis <curtisr7@gmail.com>
> Subject: Re: How to persist duplicate of an entity?
> To: users@openjpa.apache.org
> 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 <struberg@yahoo.de>
> 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 <kwsutter@gmail.com>
> wrote:
> >
> > > From: Kevin Sutter <kwsutter@gmail.com>
> > > Subject: Re: How to persist duplicate of an
> entity?
> > > To: users@openjpa.apache.org
> > > 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 <jerry@jerrycarter.org>
> > > 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
> >
> >
> >
> >
> 


      


Mime
View raw message