openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Serialization problem
Date Wed, 12 Mar 2008 01:15:58 GMT
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  

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.
> Thanks,
> -Reece

Craig Russell
Architect, Sun Java Enterprise System
408 276-5638
P.S. A good JDO? O, Gasp!

View raw message