[ROO-1238] Implement new update / create / acquire / delete events Created: 18/Aug/10  Updated: 30/Sep/10  Resolved: 21/Sep/10

Status: Resolved
Project: Spring Roo
Component/s: GWT
Affects Version/s: None
Fix Version/s: 1.1.0.RC1

Type: Improvement Priority: Blocker
Reporter: Ray Ryan Assignee: Ray Ryan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: 2d
Time Spent: Not Specified
Original Estimate: 2d

Issue Links:
is related to ROO-1402 Use EntityProxyId instead of ProxyImp... Resolved


Design doc that address the concerns below: https://wave.google.com/wave/#restored:search,restored:wave:googlewave.com%252Fw%252Bywx8dL_XC

We have put the server entirely in charge of notifying the client when records change. But the server doesn't have enough information to do this correctly.

The worst case:

Client receives Foo

{ prop1: value1}

On the server it has changed to Foo

{prop1: value2}

The client prop1 to the same value, Foo

{prop1: value2}

When the server does its diff, value2 == value2, so it reports no change, and the client does not update to reflect the edit.

The solution is to use a hybrid of the update schemes from M2 and M3: In addition to returning the simple list of objects that have changed as detected by the diff, the server also returns the entire new state of any objects that were in the delta list. The client uses this new state payload to perform the same merge-style update detection that it used to do.

(However, the client should not actually mutate its master objects as a side effect of this merge, which was its habit in M2. It should instead work in copy-on-write style — the newly received object is the new master.)

Other questions to answer:

• should we merge the old master into the new master?
• m3 is announcing updates only after a delta attempt. m2 announced them if it detected changes on succeeding gets. Shouldn't we bring back that m2 behavior?

Clearly, we should not bring back the old habit of merging values from the client side delta value store into anything.

Comment by Ray Cromwell [ 26/Aug/10 ]

Why are we not using object versioning? If the client just transmits the last version number of the object it had to the server, the server need only compare that to the version number in the datastore in order to know whether or not to send the complete object down?

Comment by Amit Manjhi [ 27/Aug/10 ]

Actually, it turns out that version number alone is not sufficient to determine whether to send down the object or not. Imagine that the server has a complex instance method on an entity Employee

public void persistNameOrSalary(...) {
if (condition_foo)

{ // only update the name }


{ // only update the salary }


The client sets both the salary and name of an Employee, and invokes the instance method. In the response, the version number alone is insufficient for the client to determine what the final state of the Employee is.

Comment by Chris Ramsdale [ 09/Sep/10 ]

This sounds like a large change with design implications, bumping this up to a Blocker.

Comment by Amit Manjhi [ 09/Sep/10 ]

This task also includes using EntityProxyId instead of ProxyImpl in postChangeEvent.

Comment by Amit Manjhi [ 09/Sep/10 ]

Better description and higher priority.

Note that SyncResults should be gone when this and Roo 954 are done

Comment by Amit Manjhi [ 15/Sep/10 ]

Created https://jira.springsource.org/browse/ROO-1401 so that this bug can be closed once SyncResult has been removed. Already added the various events as per the design wave linked above.

Comment by Ray Ryan [ 19/Sep/10 ]

The events are still returning proxy objects, not EntityProxyId.

Comment by Amit Manjhi [ 20/Sep/10 ]

Ray: can this bug be closed, in light of https://jira.springsource.org/browse/ROO-1401 and https://jira.springsource.org/browse/ROO-1402?

Comment by Ray Ryan [ 20/Sep/10 ]

It can be closed once http://gwt-code-reviews.appspot.com/902801/show is submitted, which includes the fix hide the proxy from receivers of ProxyChangeEvent. Until then, this very visible API change was not complete, and should not have been marked so.

If ROO-1402 was meant to document this fact, it failed to do so. It's phrased in terms of an invisible implementation detail.

Comment by Amit Manjhi [ 20/Sep/10 ]

My mistake.

Generated at Sat Dec 15 09:58:35 UTC 2018 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.