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.
