openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: Serialization problem
Date Thu, 13 Mar 2008 06:11:06 GMT
Hi,

You might want to read up on the openjpa.DetachState property [1]. In
particular, take a look at the behavior when the property is set to
'fetch-groups'. Are those semantics close to what you're looking for?

-Patrick

On Wed, Mar 12, 2008 at 2:48 PM, Craig L Russell <Craig.Russell@sun.com> wrote:
> Hi Reece,
>
>  Just to reiterate my position: It should be the responsibility of
>  OpenJPA to efficiently serialize instances without requiring our users
>  to write elaborate workarounds.
>
>
>  On Mar 12, 2008, at 1:36 PM, Reece Garrett wrote:
>
>  > Craig,
>  >
>  > Thanks for your response. I think what you suggest would be an
>  > excellent feature to have but I'm not sure it would address my
>  > issue. Basically I need to know if a field was set to null because:
>  >
>  > A) it was in an active fetch group and the retrieved value was null,
>  > B) the field was not in an active fetch group and was never
>  > initialized.
>  >
>  > If A is true then I serialize an empty node for that field. If B is
>  > true then I skip the field.
>
>  The detached object state is supposed to disambiguate these cases. Are
>  you using this feature of OpenJPA?
>
> >
>  > Originally I had my setter methods add the field's name to a list
>  > which I later used to determine which fields were involved in a
>  > fetch and thus needed to be serialized (null or not). However,  my
>  > logs indicate that OpenJPA initializes all fields to null (using the
>  > setter methods)
>
>  This is a bug. There is no reason to initialize fields to null because
>  the vm already did this. Can you file a JIRA?
>
>
>  > before populating persistence capable objects so all of my fields
>  > end up in the list...no good. I could do something hacky like only
>  > store a field's name if it is either set to a non-null value or set
>  > to null at least twice (once for initialization and then again if
>  > the value pulled is null). I would rather not do that.
>
>  I agree.
>
> >
>  > Why not just use the default constructor instead of explicitly
>  > setting all fields to null? Is there anything I can do about this
>  > behavior?
>
>  See above. This should be fixed.
>
>  Craig
>
>
> >
>  >
>  > -Reece
>  >
>  >
>  >
>  >
>  >>>> Craig L Russell <Craig.Russell@Sun.COM> 3/11/2008 6:15 PM >>>
>  > Hi Reece,
>  > The original design for fetch plans comes from JDO, where you can
>  > specify both fields to load and fields to unload (setting their Java
>  > value to null) before serializing them.
>  >
>  > So the only impact of an unloaded field is to write null to the
>  > output stream.
>  >
>  > I'm not sure whether the unload fields ever made it into a JIRA for
>  > OpenJPA. You can see some of the dialog here: http://www.mail-archive.com/open-jpa-dev@incubator.apache.org/msg01663.html
>  >
>  > It seems to me that adding the ability to specify that fields should
>  > be unloaded would address your requirement quite well.
>  >
>  > Craig
>  >
>  > On Mar 11, 2008, at 3:57 PM, Reece Garrett wrote:
>  > Greetings all,
>  >
>  > I am trying to do some intelligent serialization of my persistence
>  > capable classes. By intelligent I mean that only fields that were in
>  > an active fetchgroup during retrieval should be serialized (whether
>  > they are null or not).
>  >
>  > Currently I am storing a transient list of properties that should be
>  > serialized in the model objects themselves. After retrieving the
>  > object I populate the list by inspecting the fetchgroups that were
>  > used for the retrieval. The list is then used by xsteam to determing
>  > if a property of the object should be serialized. It is working but
>  > it's neither pretty nor performant. Ideally, I want each active
>  > fetchgroup to fire a postload event and a callback receive a
>  > reference to the object being retrieved and a reference to the
>  > fetchgroup that generated the event. I could then inspect the
>  > fetchgroup attributes and populate my list. Unfortunately, the
>  > callback only gets a reference to the object being retrieved so I
>  > cannot figure out which properties were loaded.
>  >
>  > Any insite is much appreciated.
>  >
>  > Thanks,
>  > -Reece
>  >
>  >
>  >
>  > Craig RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/jdo408
>  >  276-5638 mailto:Craig.Russell@sun.comP.S. A good JDO? O, Gasp!
>  >
>  >
>  >
>  >
>  >
>
>  Craig Russell
>
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>  408 276-5638 mailto:Craig.Russell@sun.com
>  P.S. A good JDO? O, Gasp!
>
>



-- 
Patrick Linskey
202 669 5907

Mime
View raw message