Me too. But my interpretation of the documentation (which could be wrong) led me to believe that even without a detached state field OpenJPA can still tell the difference between unloaded and null fields.
http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/manual.html#ref_guide_detach I believe the following section is the one that seems to pertain to my use case... If the instance has a Version field, OpenJPA will consider the object detached if the version field has a non-default value, and new otherwise. Similarly, if the instance has GeneratedValue primary key fields, OpenJPA will consider the object detached if any of these fields have non-default values, and new otherwise. When attaching null fields in these cases, OpenJPA cannot distinguish between a field that was unloaded and one that was intentionally set to null. In this case, OpenJPA will use the current detach state setting to determine how to handle null fields: fields that would have been included in the detached state are treated as loaded, and will in turn set the corresponding attached field to null. So what exactly happens when detached state fields are disabled in this scenario (e.g. @DetachedState(enabled=false))? I was under the impression OpenJPA could still make the differentiaion without the detached state field, albeit less efficiently. Regards, -jmh On Fri, Aug 21, 2009 at 9:36 AM, Daryl Stultz<da...@6degrees.com> wrote: > On Fri, Aug 21, 2009 at 9:26 AM, Jason Hanna < > jason.m.hanna.at.coincid...@gmail.com> wrote: > >> >> It is *most definitely* a JPA-related issue, either due to a bug or >> some configuration minutia. > > > I believe it is simply a matter of state management. OpenJPA can't tell the > difference between an unloaded property and a null property. I.e. when your > object comes back from AMF, the property is null, but because you've > disabled detached state management, there is nothing to tell OpenJPA that > the field was deliberately set null vs. the field having not been loaded > prior to serialization. > > I'm sure someone will correct me if I'm wrong. > > -- > Daryl Stultz > _____________________________________ > 6 Degrees Software and Consulting, Inc. > http://www.6degrees.com > mailto:da...@6degrees.com >
