Hi Sami - 1) To track the previous state would seem to require doubling the amount of data sent from server to client, which doesn't seem like a good tradeoff in general. My proposal avoids the need to send extra data by simply allowing everything to be marked as dirty.
What are your specific questions about collections and PersistentSet? 2) The only places I can see to store the extra field data are a) on the client or b) in the persistent store. The HTTP session won't work, I think. For example, the server could be behind a load-balancer, so the object would be materialized on server A, sent to the client, and sent back to server B. If the extra data is not sent along with the object, it has to be somewhere that both A and B can access. It can't just live in A's VM heap. My thought is that it would be counterintuitive for GWT RPC to attempt to modify the persistent store, and probably would create problems. Dan On Wed, Jul 22, 2009 at 9:31 AM, Sami Jaber <[email protected]> wrote: > 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 (דניאל רייס) <[email protected] > > 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 -~----------~----~----~----~------~----~------~--~---
