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


Mime
View raw message