Hi
I've seen this happen when an entity is serialized and deserialized. During
the serialization process the State of the entity was lost. So when the
entity was reattached OpenJPA couldn't differentiate between an unloaded
field and one that was intentionally set to null.
To resolve the problem you can add the following property to persistence.xml
:
<property name="openjpa.DetachState"
value="fgs(DetachedStateField=true)" />
The real key here is the DetachedStateField=true part which instructs
OpenJPA to save the State of the entity when it is serialized and
deserialized.
This option needs to be in your persistence.xml when the entities are
enhanced. If you use static enhancement via the PCEnhancer tool you'll have
to re-run the tool after updating persistence.xml. If you don't use static
enhancement the container will enhance your entities for you - so you'll
just need to redeploy.
Hope this helps,
-Mike
On Fri, Mar 7, 2008 at 2:28 PM, <[EMAIL PROTECTED]> wrote:
> Yes, that's exactly what I am seeing, and perhaps I didn't give enough
> detail...
>
> In my case, the EJB service fetches the entity, it gets detached when it
> moves from the EJB container to the web tier, user updates the entity, pass
> it back to the service where it's "merged"... the fields that were nulled
> are not getting persisted. It has to do with detaching the entity then
> re-attaching it again.
>
> I've found a HACK (emphasis on HACK) to solve it in the interim.. I
> basically take the detached entity, re-fetch the managed one, copy
> properties from the detached to the managed entity, then let the managed
> entity persist normally. But it gets tedious when you're dealing with
> entities with 30-40 attributes and you can't use the Commons copyProperties
> because of version columns, etc. (fields that are restricted).
>
> If there is a better solution, I'd be more than happy to entertain it!
>
> Thanks!
> Randy
> >
> > From: Tedman Leung <[EMAIL PROTECTED]>
> > Date: 2008/03/07 Fri PM 01:34:32 CST
> > To: [email protected]
> > Subject: Re: Newly null fields not being persisted?
> >
> > I reported this as a bug earlier and I never heard back, it still
> occurs.
> > A more detiled explanation of what I found is as follows :
> >
> > - If you have a new entity with null fields, the fields will save as
> null.
> >
> > - If you have an entity which is attached, you can nullify fields as
> long
> > as it persists itself. i.e. without you calling the merge method.
> >
> > - If you retrieve an entity and detach it, then null a field, then
> > reattach it (with merge), it will not nullify the field.
> >
> >
> > if anyone knows the code well enough to fix it or point me to the area
> > where the logic of this is done that would be good.
> >
> >
> >
> > On Fri, Mar 07, 2008 at 01:28:40PM -0600, [EMAIL PROTECTED] wrote:
> > > All,
> > >
> > > I'm not sure if this is a problem in MY code or OpenJPA. But, here
> are the symptoms in WAS w/ EJB Feature pack:
> > >
> > > User enters data into a form that is backed by a managed OpenJPA
> entity. Entity gets persisted successfully. User goes back to the same
> page and nullifies one of the fields (i.e., deletes a value from one of
> the fields in the form). Entity gets persisted, but, the field that was
> nulled out is not updated.
> > >
> > > Looking at the generated SQL in the WAS log, I see the first update
> that added the data, but in the second update statement, the field that was
> nulled is not included in the update (thus leaving data in the underlying
> table).
> > >
> > > Is there a setting in OpenJPA that turns this off? Or, could it (most
> likely) be a problem in my code somewhere?
> > >
> > > Any suggestions on how I can track this down and eliminate it?
> > >
> > > Cheers!
> > > Randy
> > >
> >
> > --
> > Ted Leung
> > [EMAIL PROTECTED]
> >
> > You know things are getting a little fishy when you're commenting out
> > comments.
> >
>
>
