You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Jason Hanna <ja...@gmail.com> on 2009/08/21 13:37:51 UTC
Re: Issue Merging Object w/Null Timestamp when Detached State Field
Disabled
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-...@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.
>>
>
>
Re: Issue Merging Object w/Null Timestamp when Detached State Field Disabled
Posted by Jean-Baptiste BRIAUD -- Novlog <j-...@novlog.com>.
Ok, it sound like you don't want my advice ... I won't bother you more.
set to null your field in Java code, remove the problem from your
serialization/flex/other glue and prove the bug instead of trying to
guess.
On Aug 21, 2009, at 15:26 , Jason Hanna wrote:
> Yes, the date is set null outside the JVM and correctly passed back to
> my DAO. The DAO manages the JPA persist, delete, and/or merge
> operations.
>
> I can see within my debugger the field is null prior to the merge, and
> reset to its previous value after the merge. Logging is set to TRACE
> and I can see no update statements are issued as a result of this
> merge.
>
> It is *most definitely* a JPA-related issue, either due to a bug or
> some configuration minutia. At this point I'm really looking for
> someone from the OpenJPA team to comment on the issue, so I can
> determine a test case and bug report are warranted.
>
> I don't want to get off on a side topic about AMF (Adobe)
> serialization. It's not an issue with my POJO relationships that
> requires me to disable the detached state field, but how the detached
> state field object itself is serialized by AMF.
>
> Field or accessor annotation shouldn't matter (it's accessor).
>
> -jmh
>
> On Fri, Aug 21, 2009 at 8:58 AM, Jean-Baptiste BRIAUD --
> Novlog<j-...@novlog.com> wrote:
>> 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-...@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-...@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.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: Issue Merging Object w/Null Timestamp when Detached State
Field Disabled
Posted by Jody Grassel <fy...@gmail.com>.
Good afternoon, Jason
I was wondering if you could share a little more detail about the entity
class itself, is the date field eager or lazy loaded by default? I
tried to reproduce the problem you're encountering without much success.
Thinking about what was described in the previous notes, I have to
wonder: is your date field eager or lazy loaded? When you get a managed
entity object back from OpenJPA, it embeds a lot of internal metadata,
so it can track changes (this metadata is serialized along with the
normal model data). One bit of metadata, I would expect, is whether a
field was faulted in during the time the entity was managed by a
persistence context. If a lazy loaded field was not faulted in before
the entity became detached, then it was probably null to begin with;
which means on merge, the persistence manager will have to assume that
the null means there was no change. It must do this to fulfill the JPA
1.0 contract section 3.2.4.1:
"The persistence provider must not merge fields marked LAZY that have
not been fetched: it must ignore such fields when merging."
Re: Issue Merging Object w/Null Timestamp when Detached State Field
Disabled
Posted by Jason Hanna <ja...@gmail.com>.
Right on. I'm thinking a basic field such as a date would always be
considered loaded. The documentation is a little ambiguous around this
point and I'm not quite ready to dig into the OpenJPA source code just
yet.
I think posting a bug with a simplified test case is my next step, I
just wanted to make sure I wasn't completely mis-reading the
documentation before moving an issue report forward.
-jmh
On Fri, Aug 21, 2009 at 10:31 AM, Daryl Stultz<da...@6degrees.com> wrote:
> On Fri, Aug 21, 2009 at 10:18 AM, Jason Hanna <
> jason.m.hanna.at.coincident@gmail.com> wrote:
>
>> 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.
>>
>
> I would say, if you think it's a bug, create a test case with an entity that
> defines a field that "would have been included in the detached state".
> Persist an instance, detach it, set the field to null, merge it, verify the
> null value in the database. The question for me is, what qualifies as a
> field that "would have been included in the detached state". I would think
> a Date would always be loaded. Of course, there is the scenario in which the
> entity is instantiated from a native query that doesn't select the Date
> field. Then it is truly unloaded and should not update the DB with null.
>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:daryl@6degrees.com
>
Re: Issue Merging Object w/Null Timestamp when Detached State Field
Disabled
Posted by Daryl Stultz <da...@6degrees.com>.
On Fri, Aug 21, 2009 at 10:18 AM, Jason Hanna <
jason.m.hanna.at.coincident@gmail.com> wrote:
> 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.
>
I would say, if you think it's a bug, create a test case with an entity that
defines a field that "would have been included in the detached state".
Persist an instance, detach it, set the field to null, merge it, verify the
null value in the database. The question for me is, what qualifies as a
field that "would have been included in the detached state". I would think
a Date would always be loaded. Of course, there is the scenario in which the
entity is instantiated from a native query that doesn't select the Date
field. Then it is truly unloaded and should not update the DB with null.
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: Issue Merging Object w/Null Timestamp when Detached State Field
Disabled
Posted by Jason Hanna <ja...@gmail.com>.
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.coincident@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:daryl@6degrees.com
>
Re: Issue Merging Object w/Null Timestamp when Detached State Field
Disabled
Posted by Daryl Stultz <da...@6degrees.com>.
On Fri, Aug 21, 2009 at 9:26 AM, Jason Hanna <
jason.m.hanna.at.coincident@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:daryl@6degrees.com
Re: Issue Merging Object w/Null Timestamp when Detached State Field
Disabled
Posted by Jason Hanna <ja...@gmail.com>.
Yes, the date is set null outside the JVM and correctly passed back to
my DAO. The DAO manages the JPA persist, delete, and/or merge
operations.
I can see within my debugger the field is null prior to the merge, and
reset to its previous value after the merge. Logging is set to TRACE
and I can see no update statements are issued as a result of this
merge.
It is *most definitely* a JPA-related issue, either due to a bug or
some configuration minutia. At this point I'm really looking for
someone from the OpenJPA team to comment on the issue, so I can
determine a test case and bug report are warranted.
I don't want to get off on a side topic about AMF (Adobe)
serialization. It's not an issue with my POJO relationships that
requires me to disable the detached state field, but how the detached
state field object itself is serialized by AMF.
Field or accessor annotation shouldn't matter (it's accessor).
-jmh
On Fri, Aug 21, 2009 at 8:58 AM, Jean-Baptiste BRIAUD --
Novlog<j-...@novlog.com> wrote:
> 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-...@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-...@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.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: Issue Merging Object w/Null Timestamp when Detached State Field Disabled
Posted by Jean-Baptiste BRIAUD -- Novlog <j-...@novlog.com>.
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-...@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-...@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.
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: Issue Merging Object w/Null Timestamp when Detached State Field
Disabled
Posted by Jason Hanna <ja...@gmail.com>.
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-...@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-...@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.
>>>>
>>>
>>>
>>
>
>
Re: Issue Merging Object w/Null Timestamp when Detached State Field Disabled
Posted by Jean-Baptiste BRIAUD -- Novlog <j-...@novlog.com>.
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-...@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.
>>>
>>
>>
>