Yes, this is a workaround I figured already. But the downside is that we need to tweak a lot of classes and it is really a bug imo. It's not a showstopper, but it's a bug ;) See OPENJPA-1912.
I'm currently writing a unit test in the openjpa-persistence-jdbc test package org.apache.openjpa.enhance. My goal is to somehow generate super.readExternal() and super.writeExternal() to subsequently process the parent class. Does this make sense to you? LieGrue, strub --- On Mon, 1/24/11, Rick Curtis <curti...@gmail.com> wrote: > From: Rick Curtis <curti...@gmail.com> > Subject: Re: way to restore the DetachedStateManager on deserialisation? > To: "dev@openjpa.apache.org" <dev@openjpa.apache.org> > Date: Monday, January 24, 2011, 1:15 PM > What happens if you change your > private fields to protected? > > Thanks, > Rick > > On Jan 24, 2011, at 5:51 AM, Mark Struberg <strub...@yahoo.de> > wrote: > > > Hi! > > > > I've tried it again and it works (maybe I had a typo > in my config, who knows). > > > > So I now get the pcStateManager back, but now another > issue appears: the code uses Externalizable and the > generated readExternal and writeExternal try to also write > the parent fields. This is bad since it doesn't work for > private fields... > > I will file a jiraffe. > > > > LieGrue, > > strub > > > > --- On Tue, 1/18/11, Mark Struberg <strub...@yahoo.de> > wrote: > > > >> From: Mark Struberg <strub...@yahoo.de> > >> Subject: Re: way to restore the > DetachedStateManager on deserialisation? > >> To: dev@openjpa.apache.org > >> Date: Tuesday, January 18, 2011, 4:31 PM > >> the pcStateManager is null after > >> deserialisation as far as I've seen. > >> > >> I'll give it another debug run tomorrow to be 100% > sure > >> about that. > >> > >> > >> LieGrue, > >> strub > >> > >> --- On Tue, 1/18/11, Michael Dick <michael.d.d...@gmail.com> > >> wrote: > >> > >>> From: Michael Dick <michael.d.d...@gmail.com> > >>> Subject: Re: way to restore the > DetachedStateManager > >> on deserialisation? > >>> To: dev@openjpa.apache.org > >>> Date: Tuesday, January 18, 2011, 4:26 PM > >>> Hi, > >>> > >>> DetachedStateField=true should do the trick. > When you > >> use > >>> that configuration > >>> option does the statemanager get serialized > and then > >> forget > >>> about _loaded? > >>> Or is it never serialized at all? > >>> > >>> -mike > >>> > >>> On Tue, Jan 18, 2011 at 4:33 AM, Mark Struberg > <strub...@yahoo.de> > >>> wrote: > >>> > >>>> Hi! > >>>> > >>>> Currently detached entities behave > completely > >>> different if they are 'just' > >>>> detached or if they got > serialised/deserialised. > >> This > >>> is almost solely due > >>>> to _pcStateManager == null after the > >> serialisation. > >>>> > >>>> After serialisation we basically miss > _dirty and > >>> _loaded information in our > >>>> entities, which has a few very bad side > effects. > >>>> > >>>> The one which currently annoy me most is > that > >> setting > >>> a field to null > >>>> doesn't get stored to the database. This > is > >> caused > >>> because we don't have the > >>>> _loaded information anymore and thus > cannot know > >> if > >>> the field is null > >>>> because it never got loaded or if it got > set to > >> null > >>> manually. > >>>> > >>>> Now my question: is it possible to restore > the > >>> DetachedStateManager on > >>>> deserialisation somehow? There is already > an > >> option > >>> for if: > >>>> > >>>> <property name="openjpa.DetachState" > >>>> > value="loaded(DetachedStateField=true)"/> > >>>> > >>>> But either I'm making something wrong, or > it > >> just > >>> doesn't work. Any hints > >>>> on that? > >>>> > >>>> Btw: I'm mainly working with compiletime > >> enhanced > >>> classes, but I guess the > >>>> basic problem remains the same in any > >> enhancement > >>> case. > >>>> > >>>> txs and LieGrue, > >>>> strub > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >> > >> > >> > >> > > > > > > >
