Sorry, yes, it was an EntityProxy. My ideas to solve it were:
1) Use a ValueProxy instead of an EntityProxy 2) Use a ValueProxy for the @Transient String value (dunno how a transient value, expressed as a ValueProxy within an EntityProxy, would be handled, or if it's allowed) 3) Pass the changing/unchanging value as a separate String argument in the RF call 4) Intuit it is unchanged BECAUSE it is null, since the client always sets it to something, but never to null I think #3 is the easiest in this case. Is there any possibility that, in future releases (we're one release behind current), an individual field in a proxy can be set to 'changed'? That is, override the default returned by isChanged()? I think that could be very useful, and I don't see it as causing any hiccups in the way things already work. - Tim On Wednesday, October 26, 2016 at 10:59:43 PM UTC-7, Thomas Broyer wrote: > > Assuming an EntityProxy here, if the field is left unchanged, then it's > not sent to the server. On the server side, the entity is loaded by the > Locator and then the diff is applied. So if the Locator gets a null field, > it'll be left null. > You may have to use a ValueProxy here… -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
