locked
What kind of changes to expect in ChangeSetResponse.UpdatedItems? RRS feed

  • Question

  • Currently i am working on a custom OfflineSyncProvider implementation. ;-)

    While implementing OnChangeSetUploaded i wonder what kind of changes to expect in ChangeSetResponse.UpdatedItems ?

    Unfortunatly OfflineSyncProvider documentation is not yet complete and doesn't give any details. At least the Guidelines for Implementing Clients for Sync Services gives us a few words:

    "These changes contains acknowledgement from server for client inserts or errors and conflicts. For inserts, save the EntityId, EntityEtag and EntityEditUri metadata values to the local store."

    To me this reads as if there will be no changes in the actual entity's value properties here and that the only thing to take care of is metadata, errors and conflicts. On the other hand, the provided WM65ClientCacheController sample performs a complete update of all columns in the underlying storage both from SaveChangeSet and OnChangeSetUploaded.

    Of course i want to make sure not to loose any data from the server response. Please advise.

     

    Friday, January 14, 2011 11:24 AM

Answers

  • Hi M.Bi,

    As mentioned in the documentation, the ChangeSetResponse.UpdatedItems collection is a readonly collection of entities uploaded by the client that have been issued permanent IDs by the service. Today the service returns the full entity back along with the tempId and the entityId (atomId) for the entity. (In the future we may choose to only return the tempId and the entityId for mapping on client.)

    You are correct in assuming that there will be no changes to the entity property values in in the UpdatedItems collection. You can safely follow the instructions in the "guidelines for implementing client for sync services" page. 


    SDE, Sync Framework - http://www.giyer.com
    • Marked as answer by M.Bi Monday, January 17, 2011 7:53 AM
    Friday, January 14, 2011 6:31 PM
  • The Updated items may fall under two categories

    1. Just the entity with no Error or Conflict values attached. This normally refers to the successful ack of a client side insert on the server. In this case you will have to sotre the metadata values the server returned. But it might be possible that the server might have changed some values of certain columns due to some business logic on server.

    2. Entity which have Error and Conflicts - This is the other one. There is one caveat though. If the client sent an insert and it had a conflict or error on the server then the winning/current value of the entity on server will be in the live one. So for an client insert that had a insert-insert conflict and user took a resolution of server wins the columns values might have changed.

    You will have to hold some reference to indicate that the losing entity in the updated item is the actual insert as opposed to the live value. However if you think logically if the client applies all values from the "Live" version then its technically in sync with the server. The Wm6.5 client doesnt persist errors or conflicts and hence it always takes and updates all non pk columns from the list. Hope this helps.


    Maheshwar Jayaraman - http://blogs.msdn.com/mahjayar
    • Marked as answer by M.Bi Monday, January 17, 2011 7:53 AM
    Friday, January 14, 2011 6:33 PM
  • Hi M.Bi,

    Tombstones that are applied successfully on the server are not sent back in the response. You will have to keep track of tombstones that you sent up and delete them locally if they don't show up in Conflicts/Errors collections in the response.

    The WM6.5 sample uses a generic apply method that can also handle tombstones. We use this method when applying conflicts/error entities too. Technically, the method that deals with applying entities from the UpdatedItems collection does not need to deal with tombstones.


    SDE, Sync Framework - http://www.giyer.com
    • Marked as answer by M.Bi Tuesday, January 18, 2011 7:46 AM
    Monday, January 17, 2011 6:44 PM

All replies

  • Hi M.Bi,

    As mentioned in the documentation, the ChangeSetResponse.UpdatedItems collection is a readonly collection of entities uploaded by the client that have been issued permanent IDs by the service. Today the service returns the full entity back along with the tempId and the entityId (atomId) for the entity. (In the future we may choose to only return the tempId and the entityId for mapping on client.)

    You are correct in assuming that there will be no changes to the entity property values in in the UpdatedItems collection. You can safely follow the instructions in the "guidelines for implementing client for sync services" page. 


    SDE, Sync Framework - http://www.giyer.com
    • Marked as answer by M.Bi Monday, January 17, 2011 7:53 AM
    Friday, January 14, 2011 6:31 PM
  • The Updated items may fall under two categories

    1. Just the entity with no Error or Conflict values attached. This normally refers to the successful ack of a client side insert on the server. In this case you will have to sotre the metadata values the server returned. But it might be possible that the server might have changed some values of certain columns due to some business logic on server.

    2. Entity which have Error and Conflicts - This is the other one. There is one caveat though. If the client sent an insert and it had a conflict or error on the server then the winning/current value of the entity on server will be in the live one. So for an client insert that had a insert-insert conflict and user took a resolution of server wins the columns values might have changed.

    You will have to hold some reference to indicate that the losing entity in the updated item is the actual insert as opposed to the live value. However if you think logically if the client applies all values from the "Live" version then its technically in sync with the server. The Wm6.5 client doesnt persist errors or conflicts and hence it always takes and updates all non pk columns from the list. Hope this helps.


    Maheshwar Jayaraman - http://blogs.msdn.com/mahjayar
    • Marked as answer by M.Bi Monday, January 17, 2011 7:53 AM
    Friday, January 14, 2011 6:33 PM
  • Thank you very much for the clarification. This helped me a lot.

    But what about tombstones? Would they ever be included in a ChangeSetResponse? From what i have found by playing with it they are not included in the response and thus i have to keep track of any changes sent to the server so i can delete them if there is no other related response (error or conflict). On the other hand, the provided WM65 example checks for tombstones in response.UpdatedItems collection and deletes from underlying storage if found. To me this seems a bit of a duplicate in the example code, isn't it?
    Monday, January 17, 2011 1:42 PM
  • Hi M.Bi,

    Tombstones that are applied successfully on the server are not sent back in the response. You will have to keep track of tombstones that you sent up and delete them locally if they don't show up in Conflicts/Errors collections in the response.

    The WM6.5 sample uses a generic apply method that can also handle tombstones. We use this method when applying conflicts/error entities too. Technically, the method that deals with applying entities from the UpdatedItems collection does not need to deal with tombstones.


    SDE, Sync Framework - http://www.giyer.com
    • Marked as answer by M.Bi Tuesday, January 18, 2011 7:46 AM
    Monday, January 17, 2011 6:44 PM