locked
Expected behavior of ISimpleSyncProvider::UpdateItem RRS feed

  • Question

  • What my provider should do if passed in objectData and keyAndExpectedVersion have different keys? Should I delete the item with the key specified by keyAndExpectedVersion and insert new objectData?
    Friday, April 16, 2010 10:44 PM

Answers

  • Maybe I'm missing something here. I observed keyAndUpdateVersion and objectData has different keys during a conflict resolution. Allow me to layout step-by-step (what I think) is happening.

     

    The two stores have different constrain resolution policy, the remote store says "Rename source", and the local store says "Destination wins". The sync direction is "upload and download". Each store starts with a single item with a key "1":

     

    Store A                                     Store B

    =================          =================

    #1, Key=1, Name=”ABC”            #2, Key=1, Name=”DEF”

     

    During upload, source is assigned a new key “2” then inserted. Note at this point the change recorded by Store B is “Item #1 is UPDATED (from Key 1 to Key 2),  and then Item #1 is CREATED”.

     

    Store A                                     Store B

    =================          =================

    #1, Key=1, Name=”ABC”            #2, Key=1, Name=”DEF”

                                                     #1, Key=2, Name=”ABC”

     

    Then, during download, the change list “Item #1 is UPDATED (from Key 1 to Key 2), and then Item #1 is CREATED”. is applied to A. First the UPDATE:

     

    Store A                                     Store B

    =================          =================

    #1, Key=2, Name=”ABC”            #2, Key=1, Name=”DEF”

                                                     #1, Key=2, Name=”ABC”

     

    then the CREATE:

     

    Store A                                     Store B

    =================          =================

    #1, Key=2, Name=”ABC”            #2, Key=1, Name=”DEF”

    #3, Key=1, Name=”DEF”             #1, Key=2, Name=”ABC”

     

    Then the two stores end up in sync. I observed the difference at the step of applying UPDATE, when the original Key of #1 is 1 (passed in via keyAndUpdateVersion) but objectData has Key 2. if I throw an error here, how this constraint be resolved?

     

    Wednesday, April 21, 2010 8:28 PM
  • Sorry for the delayed response.

    Isn't the above outcome expected? You renamed the source during upload and then that propogated back during download.  Constraint is resolved, stores are in sync.

    -Jesse

    Thursday, April 29, 2010 11:19 PM

All replies

  • Hi there,

    The keyAndExpectedVersion should match the current local key, not the soon to be updated key.  You will construct the new keyAndUpdateVersion based on the passed on objectData and pass that back.

    If the keyAndExpectionVersion and local key are different then it's a optimistic concurrency violation and you should report a recoverable error. 

    -Jesse

    Tuesday, April 20, 2010 6:04 PM
  • Maybe I'm missing something here. I observed keyAndUpdateVersion and objectData has different keys during a conflict resolution. Allow me to layout step-by-step (what I think) is happening.

     

    The two stores have different constrain resolution policy, the remote store says "Rename source", and the local store says "Destination wins". The sync direction is "upload and download". Each store starts with a single item with a key "1":

     

    Store A                                     Store B

    =================          =================

    #1, Key=1, Name=”ABC”            #2, Key=1, Name=”DEF”

     

    During upload, source is assigned a new key “2” then inserted. Note at this point the change recorded by Store B is “Item #1 is UPDATED (from Key 1 to Key 2),  and then Item #1 is CREATED”.

     

    Store A                                     Store B

    =================          =================

    #1, Key=1, Name=”ABC”            #2, Key=1, Name=”DEF”

                                                     #1, Key=2, Name=”ABC”

     

    Then, during download, the change list “Item #1 is UPDATED (from Key 1 to Key 2), and then Item #1 is CREATED”. is applied to A. First the UPDATE:

     

    Store A                                     Store B

    =================          =================

    #1, Key=2, Name=”ABC”            #2, Key=1, Name=”DEF”

                                                     #1, Key=2, Name=”ABC”

     

    then the CREATE:

     

    Store A                                     Store B

    =================          =================

    #1, Key=2, Name=”ABC”            #2, Key=1, Name=”DEF”

    #3, Key=1, Name=”DEF”             #1, Key=2, Name=”ABC”

     

    Then the two stores end up in sync. I observed the difference at the step of applying UPDATE, when the original Key of #1 is 1 (passed in via keyAndUpdateVersion) but objectData has Key 2. if I throw an error here, how this constraint be resolved?

     

    Wednesday, April 21, 2010 8:28 PM
  • Sorry for the delayed response.

    Isn't the above outcome expected? You renamed the source during upload and then that propogated back during download.  Constraint is resolved, stores are in sync.

    -Jesse

    Thursday, April 29, 2010 11:19 PM
  • Yes i was confused with differences between my key and metadata item key.
    Wednesday, May 5, 2010 8:46 PM