On Feb 4, 2011, at 2:13 PM, Jerry Carter wrote: > Am I right is assuming that null values should be copies on merge? I've > reviewed the JPA 2.0 specification. I see that 3.2.7.1 does not disadvantage > null values >> If X is a detached entity, the state of X is copied onto a pre-existing >> managed entity instance X' of the same identity or a new managed copy X' of >> X is created. > > but note that 3.2.7.2 leaves some wiggle room for implementations supporting > lazy loading. I'm happy to file the report if this is a bug. > > I see that FetchType.EAGER is already specified (by default), so lazy loading > is already turned off for the field in question. Do I understand that > (post-merge), setting the value to null should cause the value to be > persisted?
I completed an experiment which rules this option out. Looking at the value after the merge and after a flush, I can see that the null value is present in Java but that the database is not updated. Time to review the documentation for your other suggestion: > On Feb 4, 2011, at 1:56 PM, Rick Curtis [via OpenJPA] wrote: >> That would be the problem then. We lost track of the fact that you set this >> field to null, and assume that it wasn't loaded. Please review the >> openjpa.DetachState [1] docs for more info. You could set the property >> listed below so that we will stream our DetachedStateManager around. >> >> <property name="openjpa.DetachState" >> value="fetch-groups(DetachedStateField=true)"/> >> >> [1] >> http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_detach_graph -- View this message in context: http://openjpa.208410.n2.nabble.com/Null-field-not-persisted-for-Dates-tp5993519p5997071.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
