You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Reece Garrett <RG...@co.pierce.wa.us> on 2008/03/11 23:57:34 UTC
Serialization problem
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
Re: Serialization problem
Posted by Reece Garrett <RG...@co.pierce.wa.us>.
Hey Craig,
I am setting openjpa.DetachState=fetch-groups but given that OpenJPA is initializing all fields to NULL regardless of their involvment in the fetch configuration I do not see how it disambiguates the situation. If indeed the initialization behavior is a bug and were fixed then I could use my original solution (recording property access through setters).
As I was typing this response I noticed that I can use openjpa.DetachState=fetch-groups(DetachedStateManager=true,AccessUnloaded=false) and then utilize the IllegalStateExceptions during serialization. Is that what you were invisioning?
Thanks,
-Reece
>>> Craig L Russell <Cr...@Sun.COM> 3/12/2008 2:48:58 PM >>>
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 <Cr...@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!
Re: Serialization problem
Posted by Patrick Linskey <pl...@gmail.com>.
Another alternative (since it sounds like you're writing custom XML
serialization, essentially) would be to use similar logic to what the
DetachManager uses, and interrogate the OpenJPAStateManager or
ClassMetaData corresponding to each instance. Those objects will tell
you definitively what has been accessed / what is in the current fetch
configuration.
-Patrick
On Thu, Mar 13, 2008 at 12:05 PM, Reece Garrett <RG...@co.pierce.wa.us> wrote:
> Hello Patrick,
>
> I am setting openjpa.DetachState=fetch-groups but, as I explained to Craig, couldn't figure out how to determing whether NULL properties were set due to OpenJPA initializing them (a bug according to Craig) or because they were fetched NULL.
>
> Upon closer inspection of the docs I see that using openjpa.DetachState=fetch-groups(DetachedStateManager=true,AccessUnloaded=false) will block access to unloaded properties by throwing an IllegalStateException (kudos to you guys for not using an implementation specific exception). I don't like the idea of being shut out of unloaded properties but can't immediately think of situation where it could bite me in the ass and it does solve my problem.
>
> Thanks,
> -Reece
>
>
> >>> "Patrick Linskey" <pl...@gmail.com> 3/12/2008 11:11:06 PM >>>
>
>
> 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 <Cr...@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 <Cr...@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
>
--
Patrick Linskey
202 669 5907
Re: Serialization problem
Posted by Reece Garrett <RG...@co.pierce.wa.us>.
Hello Patrick,
I am setting openjpa.DetachState=fetch-groups but, as I explained to Craig, couldn't figure out how to determing whether NULL properties were set due to OpenJPA initializing them (a bug according to Craig) or because they were fetched NULL.
Upon closer inspection of the docs I see that using openjpa.DetachState=fetch-groups(DetachedStateManager=true,AccessUnloaded=false) will block access to unloaded properties by throwing an IllegalStateException (kudos to you guys for not using an implementation specific exception). I don't like the idea of being shut out of unloaded properties but can't immediately think of situation where it could bite me in the ass and it does solve my problem.
Thanks,
-Reece
>>> "Patrick Linskey" <pl...@gmail.com> 3/12/2008 11:11:06 PM >>>
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 <Cr...@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 <Cr...@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
Re: Serialization problem
Posted by Patrick Linskey <pl...@gmail.com>.
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 <Cr...@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 <Cr...@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
Re: Serialization problem
Posted by Craig L Russell <Cr...@Sun.COM>.
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 <Cr...@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!
Re: Serialization problem
Posted by Reece Garrett <RG...@co.pierce.wa.us>.
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.
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) 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.
Why not just use the default constructor instead of explicitly setting all fields to null? Is there anything I can do about this behavior?
-Reece
>>> Craig L Russell <Cr...@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!
Re: Serialization problem
Posted by Craig L Russell <Cr...@Sun.COM>.
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 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!