Spring Roo
  1. Spring Roo
  2. ROO-1238

Implement new update / create / acquire / delete events

    Details

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

      Description

      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

          Activity

          Hide
          Amit Manjhi added a comment -

          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.

          Show
          Amit Manjhi added a comment - 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.
          Hide
          Ray Ryan added a comment -

          The events are still returning proxy objects, not EntityProxyId.

          Show
          Ray Ryan added a comment - The events are still returning proxy objects, not EntityProxyId.
          Hide
          Amit Manjhi added a comment -
          Show
          Amit Manjhi added a comment - Ray: can this bug be closed, in light of https://jira.springsource.org/browse/ROO-1401 and https://jira.springsource.org/browse/ROO-1402?
          Hide
          Ray Ryan added a comment -

          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.

          Show
          Ray Ryan added a comment - 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.
          Hide
          Amit Manjhi added a comment -

          My mistake.

          Show
          Amit Manjhi added a comment - My mistake.

            People

            • Assignee:
              Ray Ryan
              Reporter:
              Ray Ryan
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 2d
                2d
                Remaining:
                Remaining Estimate - 2d
                2d
                Logged:
                Time Spent - Not Specified
                Not Specified