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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED]/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:[EMAIL PROTECTED] A good JDO? O, Gasp! > > > > > > > > > > > > Craig Russell > > > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > > -- Patrick Linskey 202 669 5907
