As a follow up this, the internal persist() method isn't called on these modified entities either.
On Thu, Oct 14, 2010 at 2:40 PM, Patrick Julien <[email protected]> wrote: > and forgot to mention, adding is fine. So if I add a new office hour > to an existing user, I get a new entity as a child of the user. > > Also somewhat related and that I forgot to mention, the user itself, > if modified, is also the right value, and is coming in from dvsDataMap > > > On Thu, Oct 14, 2010 at 2:15 PM, Patrick Julien <[email protected]> wrote: >> Simple test case: >> >> User >> Office hours >> >> I will get back entity proxies that are represent this information on >> the client. If I call edit. The entire tree is now mutable thanks to >> the latest fixes. >> >> However, if I update a sub-entity, when I fire this request back to >> the server, I have the following: >> >> 1. Client side, office hours has the right value >> 2. The json request has the right value in JsonRequestProcessor >> 3. OfficeHours.findOfficeHours is called with the right id >> 4. The right setter method is called with the right value on the >> object, again all good. >> 5. The newly modified entity is stored in dvsDataMap. Since this is a >> delta, this is again good. >> 6. The user object that is passed to the service method is the right >> one, again all good >> >> However, >> >> 7. The office hours object passed in with the user object in step #6 >> is a pristine db copy. It's not the one from dvsDataMap, it's the one >> that was collected when the user was first grabbed. So when I commit >> the object graph, I commit without any modifications >> >> so we have >> public static void persist(sessionId, userAccount) { >> userAccount is the right one, modifications and all >> but userAccount.List<officeHours> and its contents are the one from >> returned from UserAccount.findUserAccount instead of what's in >> dvsDataMap >> > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
