Hi Dan, That sounds to be a really good step in the right direction. This mecanisms seems to cover all the nominal use cases that we would face regarding the different o/r mapping impl. I would just make a few remarks :
1) When you call all the setXX() methods when the object is sent back to the server, the o/r mapper will assume that those fields have been modified and the dirty state tracking (which is activated before the setXX() call if I well understand) will raise an "update" operation for all the fields. I think you have to compare bean n-1 field values and bean n field values to call only the setXX() for the modified values. What about collection ? Hibernate provides a PersistentSet that ensure the object state tracking, will you call setXX() for all items of client data ? 2) If you analyze an enhanced entity in the Hibernate land you will see that it contains many coarse-grained information, like a SessionImplementor (it depends on the dynamic proxy factory and impl you have used) -> https://www.hibernate.org/hib_docs/v3/api/org/hibernate/proxy/ProxyFactory.html. Serializing those data in a String based representation could be potentially harmful in term of bandwith and payload. Why not providing a way to store this client data info in the HttpSession ? Sami On Mon, Jul 20, 2009 at 8:06 PM, Daniel Rice (דניאל רייס) <r...@google.com>wrote: > Hi all - > I've been working on a patch to improve support for RPC of > persistence-enhanced objects that would replace the one I recently submitted > as trunk revision 5672. I'd like to give those of you who are interested in > the interaction between RPC and persistence a chance to help me validate the > design before moving forward. > > The idea is to be able to deal with different persistence mechanisms in a > way that does not depend too much on the details of their implementations. > We assume that the persistence mechanism provides a way for instances to be > detached from the object store, serialized, deserialized, and reattached in > a well-defined way. Our strategy leverages this capability as follows: > > 1) User code on the server detaches the object and places it into a state > such that serialization is valid > 2) GWT detects whether any instance fields are present on the object that > were not known to client code > 3) GWT performs hybrid serialization: > a) GWT uses its regular RPC mechanism for the client-visible fields > b) GWT uses Java serialization for any additional server-only instance > fields > c) GWT encodes the results of step (b) as a String > d) GWT prepends the encoded String to the regular RPC data and transmits > to the client > 4) Client code treats the object in the normal way and does not interact > with the data from step (3b) > 5) When the object is sent back to the server, the normal RPC mechanism is > altered as follows > a) the encoded server data is decoded and deserialized into the new > object instance > b) the client data is populated using setXXX() method invocations rather > than by directly setting field values > > All this is done only for classes that can be send bidirectionally, and > which are determined to be (potentially) enhanced. > The potential for enhancement is signaled in one of three ways: > > o The user adds the fully-qualified class name to a 'gwt.enhancedClasses' > configuration property > o The class is determined to have the JDO @PersistenceCapable annotation > with detachable=true > o The class is determined to have the JPA @Entity annotation > > If a class is determined to be potentially enhanced, the list of fields > known to the client is added to the '.gwt.rpc' file that contains the RPC > whitelist. This list is used by step 2 of the RPC process which compares > the set of client- and server-visible fields. > > Step (5b) is necessary to accommodate mechanisms like that of JDO, where > the setter methods are enhanced to provide object state tracking (dirty > bits). If we were to set the fields directly, the object detached state > would not be updated properly. > > My hope is that this mechanism would be general enough to support a > variety of persistence mechanisms without the need to add a lot of > special-case code. I'm looking forward to any comments that you have as to > whether this will work with your favorite persistence API, or any other > thoughts that you have. Thanks, > > Dan > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
