openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reece Garrett" <>
Subject Re: Serialization problem
Date Wed, 12 Mar 2008 20:36:37 GMT

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

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 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?



>>> 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:

It seems to me that adding the ability to specify that fields should be unloaded would address
your requirement quite well.


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.

Craig RussellArchitect, Sun Java Enterprise System 276-5638
mailto:Craig.Russell@sun.comP.S. A good JDO? O, Gasp!

View raw message