Sorry, but it is not clear at all to me.
Apparently, the date is set to null outside the JVM ... am I right ?
If yes, did you try to force it to null after and before the merge
inside the JVM ?
This test will answer is the problem is in the JVM or outside.
It will also clearout OpenJPA responsability.
For exemple : If this works fine to set to null before the merge in
the JVM, then it is not an OpenJPA bug.
Also, if it is "wrongly serialized", what is the impacts ?
If an attribute A on POJO is serialized to B in flex, then B is
modified but doesn't exist on the merge operation.
Are you annotating the accessors or the fields ?
On Aug 21, 2009, at 14:38 , Jason Hanna wrote:
I've been working with OpenJPA for a while. Don't know why I've never
tried to do this before or if it's something new.
That's the idea. You detach an object so it can be passed to a client
outside your JVM for modification. In my case it's a the Flash player
on a user's browser.
Normally the detached state field and detached state manager help to
optimize the merge/re-attach process, but in my case the detached
state field was being improperly serialized by Flex and BlazeDS. The
OpenJPA docs suggest you should be able to merge detached objects
without using this field, as long as you're keeping a version field
and have primary keys properly setup and identified.
I have a rather complex model of linked objects, and merge nested,
detached objects fairly regularly in code.
Don't know why I haven't noticed this before, but it's occurring on
what seems to be a fairly trivial use case. A Date/Timestamp set to
null on the top-level object is passed in but not detected during the
attach/merge process.
Thanks for trying to help, though, and good luck with your own
projects.
Regards,
-jmh
On Fri, Aug 21, 2009 at 7:58 AM, Jean-Baptiste BRIAUD --
Novlog<j-b.bri...@novlog.com> wrote:
Are you sure the object is attached or at least merged and only
after that
you set the date to null ?
In fact, I'm not, yet:-), OpenJPA expert but it look like the
modification
happened when detached and so is ignored.
On Aug 21, 2009, at 13:37 , Jason Hanna wrote:
Yes. Classes are enhanced at build time as a task in the Maven build
process.
I suspect the issue may be related to the fact I've needed to turn
off
use of the detached state fields in order for the BlazeDS
serialization to work properly.
-jmh
On Fri, Aug 21, 2009 at 4:26 AM, Jean-Baptiste BRIAUD --
Novlog<j-b.bri...@novlog.com> wrote:
Hi Jason,
How are you enhancing your POJOs ?
If you are not enhancing them at build time, please do it and
give us
some
news.
On Aug 21, 2009, at 05:38 , jason.m.hanna wrote:
Hi All,
I'm having some trouble with my OpenJPA application and could
use some
help.
I've got a web-based application using Flex and BlazeDS to front-
end my
web
container running Tomcat, Spring, OpenJPA, and a few other
technologies.
My
back-end database is PostgreSQL.
I've got a DAO layer that works with a number of annotated
POJOs, and
everything has been working fairly smoothly until I just tried
to merge
a
detached object and set its Date (db timestamp) to null.
Somewhat surprisingly, the new null value seems to go undetected
by JPA
and
the field is never included in the generated update statement.
Hence the
date is not removed from my returned object.
Because I'm using Flex and BlazeDS, my POJOs are annotated to
disable
detached state field use.
I'm running this way as the documentation seemed to suggest this
should
work
w/o a detached state field - plus it avoids serialization issues
in
BlazeDS
and ActionScript caused by the detached state field.
Is this a bug I'm seeing or how the system is supposed to work?
Versions, etc. as follows:
OpenJPA 1.2.1 (classes enhanced @ build)
JDK 1.6.x
PostgreSQL 8.3
Tomcat 6.x
Flex 3.3
Let me know if you need more info.
Thanks!
-jmh
--
View this message in context:
http://n2.nabble.com/Issue-Merging-Object-w-Null-Timestamp-when-Detached-State-Field-Disabled-tp3484177p3484177.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
