1) According to Bob, the extra field shouldn't cost anything unless it's used. 2) The code sets the 'modified' bits when the data is deserialized on the server, i.e., it marks all the fields as dirty so the object will be fully updated when the user calls makePersistent on it. I think this is sufficent, because:
a) It's not practical to track changes on the client (for example, JSNI methods could easily bypass any mechanism we put in place), and b) AppEngine doesn't do partial updates anyway, so there's no performance advantage in that environment for trying to do more. By the way, the design is largely based on one of the emails you sent to the gwt mailing list, so thanks for helping me get some clarity on what needs to happen, Dan On Fri, Jun 26, 2009 at 4:53 PM, <cromwell...@gmail.com> wrote: > On 2009/06/26 19:57:28, Dan Rice wrote: > > Two general comments: > 1) What are the implications of stashing an extra field on > java.lang.Object, is there any impact on output size? > > 2) I've noticed that the JDO enhanced classes seem to track field > mutations and update the jdoDetachedState. This patch just seems to > preserve the original jdoDetachedState on the client by tunneling it on > an expando. What happens if an object sent from the server to the > client, has modifications performed (mutations), and then is sent back > to the server for a PersistenceManager.makePersistent() or > EntityManager.merge()? Will the PMF/EMF just decide that nothing has > changed and treat it as a no-op? > > > > > > http://gwt-code-reviews.appspot.com/47807 > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
