[
https://issues.apache.org/jira/browse/OPENJPA-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14499324#comment-14499324
]
Mark Struberg commented on OPENJPA-2559:
----------------------------------------
Do you serialize around the entity before attaching again?
I had such an effect in exact that scenario. The reason was that the _dirty and
_loaded bitfields which get generated into your entities do only properly get
serialized if you have the following set:
{quote}
<property name="openjpa.DetachState" value="loaded(DetachedStateField=true)"/>
<property name="openjpa.Compatibility"
value="IgnoreDetachedStateFieldForProxySerialization=true"/>
{quote}
For every field which is not _loaded we do _not_ set any _dirty information
when resetting the field to null. That explains why OpenJPA still believes that
this field is untouched in that case. Please ping back if your scenario doesn't
involve any serialisation or other detachment.
> OpenJPA silently ignores assigning a null value to a non-nullable column
> ------------------------------------------------------------------------
>
> Key: OPENJPA-2559
> URL: https://issues.apache.org/jira/browse/OPENJPA-2559
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.3.0
> Reporter: Vermeulen
> Attachments: NonNullable.java, NonNullableColumnTest.java
>
>
> OpenJPA should throw a PersistenceException when you merge an entity that has
> null for a field that is mapped to a non-nullable column (@Column(nullable =
> false)). This should also happen when you set the field to null for an
> attached entity and then commit the change.
> This works fine for entities that haven't been persisted yet (INSERT).
> However this does NOT happen for entities that are already persistent with a
> non-null value for the field (UPDATE). When doing entityManager.merge, the
> returned entity has null for the field, but the database still has the old
> value. The entity returned by entityManager.find also returns this old
> non-null value. Similarly, after setting the field to null on an attached
> entity and committing the transaction it is still null in the entity, but not
> in the database.
> This behavior makes it a lot harder to detect programming errors where you
> accidentally attempt to update a non-nullable column to null, or where you
> made a mistake in the mapping and actually expected the column to be
> nullable. (Unless you also use the JSR 303 @NotNull annotation.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
