Le 15 mai 2012 20:24, <[email protected]> a écrit : > > This may be a naive question, but how are immutable entities supposed to > work with the RequestContext lifecycle? > > I think the more normal approach is something like this: > > - fetch an entity using a RequestContext > - start editing it > - commit it back, using the same RequestContext
Actually, you won't use the same RC, as the first one will be locked after you used it for the fetch. You should think about an RC as a builder, that's unusable after the fire(). > Alternately you can do this: > - fetch entity > - mark as immutable (detach it) That's actually what happen every time. > - keep it in a cache for read-only purposes ...or edit it and send it back to the server. > It seems like it might be not be legitimate to start editing an > immutable entity without first re-fetching it from the server. You're > editing a random version of the entity that doesn't correspond to > anything on the server. We could create a diff based on that entity and > try to apply it to the server-side object and often it will happen to > work, but I'm not sure that's intended to work? That's exactly what happens now. Only the developer has to make sure the entity is not too old, it's its responsibility. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
