openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: AttachStrategy Question
Date Mon, 29 Nov 2010 22:46:57 GMT
Hi Michael!

Txs 4 the quick response!

Yea, you got this scenario right, I detach first (in one request), and then I set the entity
before doing the merge (JSF postback in the 2nd request). I took care that no serialisation
is involved (using CODI @ViewAccessScoped and not the JSF ViewMap), so the detached state
information should remain intact.

I'm currently building the latest from trunk and will try to reproduce the behaviour in unit
tests tomorrow morning.

txs and LieGrue,
strub

--- On Mon, 11/29/10, Michael Dick <michael.d.dick@gmail.com> wrote:

> From: Michael Dick <michael.d.dick@gmail.com>
> Subject: Re: AttachStrategy Question
> To: dev@openjpa.apache.org
> Date: Monday, November 29, 2010, 8:54 PM
> Re-read your original email, and this
> makes more sense now.
> 
> I think what's happening is that you're detaching, setting
> a field to null,
> and then merging the entity into a persistence context.
> When you flush to
> the database the field that you set to null is not saved
> (any other changed
> fields would be though).
> 
> This happens because OpenJPA makes some assumptions at
> attach time, based on
> your DetachState. If it's 'loaded' (the default) we assume
> that any null
> fields were never loaded from the database. If it's 'fgs'
> we check the fetch
> group to see whether the field _should_ have been loaded -
> if so we'll
> assume the value has been changed and write it to the
> database, if the field
> would not have been loaded in the current fetch group then
> we'll ignore
> (just like with loaded). If the detachState is set to 'all'
> then whatever is
> in the entity is written to the database (I think - I've
> never tried this
> path).
> 
> You're right - the information as to whether the field has
> ever been loaded
> should be available in most cases - and should be available
> in the detached
> state field (assuming one is available). I was under the
> impression OpenJPA
> did check the detached state field before falling into the
> AttachStrategy
> code (might need to take another look though).
> 
> At any rate, a testcase will definitely help, or if I've
> guessed wrong about
> the failing scenario let us know..
> 
> -mike
> 
> On Mon, Nov 29, 2010 at 2:38 PM, Michael Dick <michael.d.dick@gmail.com>wrote:
> 
> > Hi Mark,
> >
> > I'm not sure exactly what you're doing to cause the
> error, a unit test
> > would definitely help there.
> >
> > The openjpa.DetachState property is a way to specify
> which fields will be
> > present when an entity is detached. Using a different
> DetachState value may
> > result in different results depending on your
> fetch-group and usage pattern.
> > In either case I don't think a field would be reset to
> null at detach time
> > though.
> >
> > Maybe I've misunderstood your scenario though.
> >
> > -mike
> >
> >
> > On Fri, Nov 26, 2010 at 11:51 AM, Mark Struberg <struberg@yahoo.de>
> wrote:
> >
> >> a side note: it works if I use
> >> <property name="openjpa.DetachState"
> value="fetch-groups"/>
> >>
> >> But it looks most likely as a bug to me because I
> don't serialize the
> >> detached entity, nor do I invoke native queries to
> get it, etc - just plain
> >> JPA! So it must give me exactly the same results
> regardless of the detach
> >> strategy I use...
> >>
> >> Should I file a JIRA?
> >>
> >> LieGrue,
> >> strub
> >>
> >> --- On Fri, 11/26/10, Mark Struberg <struberg@yahoo.de>
> wrote:
> >>
> >> > From: Mark Struberg <struberg@yahoo.de>
> >> > Subject: AttachStrategy Question
> >> > To: dev@openjpa.apache.org
> >> > Date: Friday, November 26, 2010, 4:54 PM
> >> > Hi folks!
> >> >
> >> > I have a question regarding OpenJPA-2.0.1
> AttachStrategy
> >> > DETACH_LOADED.
> >> >
> >> > I have an entity with a Date field. This
> field gets filled
> >> > with the current date and stored to the
> database. Afterwards
> >> > it gets loaded from the database and
> detached. In the next
> >> > request the date will be reset to null. And
> here comes the
> >> > problem (around AttachStrategy#178):
> >> >
> >> >
> >> >         
>    case
> >> > JavaTypes.OBJECT:
> >> >         
>    case
> >> > JavaTypes.OID:
> >> >         
>    case
> >> > JavaTypes.ENUM:
> >> >           
>      val
> >> > = fetchObjectField(i);
> >> > --->         
>   if (val ==
> >> > null && !nullLoaded) <-- problem
> >> >
> >> >     return false;
> >> >
> >> > sm.settingObjectField(into, i,
> sm.fetchObjectField(i), val,
> >> >
> >> >     set);
> >> >
> >> > break;
> >> >
> >> > This leads to not getting the date field
> reset to null in
> >> > the database while merging the entity.
> >> >
> >> > Imo this should only be skipped if the field
> didn't got
> >> > loaded previously from the database. I bet
> this information
> >> > is available, but where can I get this
> information from?
> >> >
> >> > Are some bells ringing, or should I try to
> craft a unit
> >> > test?
> >> >
> >> > txs and LieGrue,
> >> > strub
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >>
> >
>



      

Mime
View raw message