Hey Craig, I am setting openjpa.DetachState=fetch-groups but given that OpenJPA is initializing all fields to NULL regardless of their involvment in the fetch configuration I do not see how it disambiguates the situation. If indeed the initialization behavior is a bug and were fixed then I could use my original solution (recording property access through setters).
As I was typing this response I noticed that I can use openjpa.DetachState=fetch-groups(DetachedStateManager=true,AccessUnloaded=false) and then utilize the IllegalStateExceptions during serialization. Is that what you were invisioning? Thanks, -Reece >>> Craig L Russell <[EMAIL PROTECTED]> 3/12/2008 2:48:58 PM >>> 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!
