[
https://issues.apache.org/jira/browse/OPENJPA-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14499501#comment-14499501
]
Vermeulen commented on OPENJPA-2559:
------------------------------------
Yes, I forgot to mention that I used these settings in the test case:
{quote}
<property name="openjpa.DetachState"
value="fetch-groups(DetachedStateField=false)" />
<property name="openjpa.AutoDetach" value="commit" />
{quote}
We have a client/server application where we serialize entities to transfer
them from server to client. The client edits the state and sends them back to
the server to merge.
I thought it would be ugly if the client depends on the presence of a detached
state field so I turned that off.
(I do think it is a valid architecture to use the entities as domain-model
objects on the client. This prevents duplicated logic and unnecessary DTO's.
The only drawback is that the client requires a library with the JPA
annotations but it shouldn't require the implementation.)
> 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)
