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 21:48:58 GMT
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 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.

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

>  276-5638 mailto:Craig.Russell@sun.comP.S. A good JDO? O, Gasp!

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

View raw message