Uploaded image for project: 'Spring Roo'
  1. Spring Roo
  2. ROO-1238

Implement new update / create / acquire / delete events


    • Type: Improvement
    • Status: Resolved
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.1.0.RC1
    • Component/s: GWT
    • Labels:


      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.

        Issue Links


          No work has yet been logged on this issue.


            • Assignee:
              rjrjr@google.com Ray Ryan
              rjrjr@google.com Ray Ryan
            • Votes:
              1 Vote for this issue
              1 Start watching this issue


              • Created:

                Time Tracking

                Original Estimate - 2d
                Remaining Estimate - 2d
                Time Spent - Not Specified
                Not Specified