openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dick <michael.d.d...@gmail.com>
Subject Re: AttachStrategy Question
Date Mon, 29 Nov 2010 20:54:14 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message