[ 
https://issues.apache.org/jira/browse/OPENJPA-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14499630#comment-14499630
 ] 

Mark Struberg commented on OPENJPA-2559:
----------------------------------------

with DetachStatefield=false you will (afaik, having fixed a few other bugs in 
that area I know it vaguely) loose all the _dirty and _loaded fields whenever 
your entity gets detached. And that will effectively lead to the aforementioned 
issues with set(null) not reflecting into the database on a merge.
If you have the entity 'attached' and call setBla(null) then it should work.

Please try using my settings.

> 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)

Reply via email to