locked
Desired behavior of ISimpleSyncProviderConstraintConflictResolver.ModifyAndUpdateRemoteItem RRS feed

  • Question

  • The document says "When overridden in a derived class, renames the remote item so that it no longer conflicts with the local item name and updates the remote item in the local replica. "  If remote item doesn't conflict with local store items then the renamed remote item has a name that doesn't exist in local store. Hence there's no local item to update but the renamed item needs to be inserted --- and isn't this covered in another method on the interface: ModifyAndInsertRemoteItem?

     

    Thursday, April 15, 2010 11:40 PM

Answers

  • I think this is that happened.

    1. ON Store A: item 100 is created (with metadata id #01, created later), on Store B: item 100 is created (with metadata id #02, created later).

    2. Sync from Store A to Store. We tried to apply item 100 on B but B has its item with user id 100 already. So we rename remote item from A as user id 200, but still its metadata id is #01.  So after sync on Store B, we have item 100(#02) and item 200(#01).

    3. Now sync from B back to A, assuming (maybe) item with metadata id #01 is enumerated first.  When applying this change, since this item was created on A so the store knows its creation verison, therefore it treats as an UPDATE. (What you observed is a designed behavior.)  However, its user id was changed from 100 to 200, and 200 was not in Store A, you think we should have INSERT.  if this is the case, you can temporarily log this change and waiting for all rest changes applied and then apply this one again.  So the next change is 100(#02) comes to store A.  We raise constraint conflict again due to Store A has 100(#01).  Since the policy is Source Win on Store A, then you should see a DELETE call on item 100(#01) and CREATE call on item 100(#02).  After this you can do INSERT 200 to the uesr store.

    BTW - I am using #01 as the metadata id format just for illustration purpose ONLY and metadata Id is not exposed.

    Thanks.


    Leo Zhou ------ This posting is provided "AS IS" with no warranties, and confers no rights.
    Saturday, April 17, 2010 7:08 PM
    Answerer
  • ModifyAndUpdateRemoteItem - When overridden in a derived class, renames the remote item so that it no longer conflicts with the local item name and updates the remote item in the local replica.
    ModifyAndInsertRemoteItem - When overridden in a derived class, renames the remote item so that it no longer conflicts with the local item name and inserts the remote item into the local replica.
    I think the difference is whether the remote item exists locally or not. If it exists - Update() is called, else - Insert(),
    Hope this helps.
    Adrian
    Monday, April 19, 2010 11:19 PM
  •  

    I think the 2 conflict situation happens in following way.

    Store 1                                       Store 2
    itemA (constraint col: 100)             itemB (constraint col: 100)
    You will get a ModifyAndInsertRemoteItem when sync from 1 to 2,
      because itemA was never in store 2 before. You can change itemA's c-col to 101, later when sync back, itemA c-col in store 1 will be changed to 101.


    Store 1                                       Store 2
    itemA (constraint col: 50)               itemA (constraint col: 50)
                                                     itemB (constraint col: 100)
    itemA now updated to constraint col:100
    You will get a ModifyAndUpdateRemoteItem when sync from 1 to 2,
      because itemA is in store 2. You can change itemA's c-col to 101, later when sync back, itemA c-col in store 1 will be changed to 101.

    Tuesday, April 20, 2010 8:21 PM
    Answerer
  • Right, if your constraint only exists for the primary key. However, if you have other constraint column, this will be easier to see.

     

    Thursday, April 22, 2010 6:16 PM
    Answerer

All replies

  • Anyone understands the different of designed bahaviors of the two methods?
    Friday, April 16, 2010 7:11 PM
  • Some additional information. I implemented a test case like this: two stores with item 1 in both stores to start. Set sync direction to UploadDownload, constraint resolution policy on remote store is "Rename source" and "Source wins" on local store. Then I started the syn and here's what happened:

    1) Item 1 is attempted to be inserted into remot store.

    2) Insertion failed, and my implementation of ISimpleSyncProviderConstraintConflictResolver.ModifyAndInsertRemoteItem is called

    3) In my implemenation I give the item a new key and INSERTed it into remote store.

    Again the problem is during the download, because the local store attempts to do an UPDATE on the item with newly assigned key. Of course the update will fail because item doesn't exist in local store. The question is that I did a INSERT in remote store, how the framework decided it was an UPDATE?

    Friday, April 16, 2010 8:57 PM
  • One moe thing. In my implementation I'm setting  updatedKeyAndVersion to the newly created key. Is this wrong? I tried to use original key it didn't work either (sync framework throws exception).
    Friday, April 16, 2010 9:01 PM
  • I think this is that happened.

    1. ON Store A: item 100 is created (with metadata id #01, created later), on Store B: item 100 is created (with metadata id #02, created later).

    2. Sync from Store A to Store. We tried to apply item 100 on B but B has its item with user id 100 already. So we rename remote item from A as user id 200, but still its metadata id is #01.  So after sync on Store B, we have item 100(#02) and item 200(#01).

    3. Now sync from B back to A, assuming (maybe) item with metadata id #01 is enumerated first.  When applying this change, since this item was created on A so the store knows its creation verison, therefore it treats as an UPDATE. (What you observed is a designed behavior.)  However, its user id was changed from 100 to 200, and 200 was not in Store A, you think we should have INSERT.  if this is the case, you can temporarily log this change and waiting for all rest changes applied and then apply this one again.  So the next change is 100(#02) comes to store A.  We raise constraint conflict again due to Store A has 100(#01).  Since the policy is Source Win on Store A, then you should see a DELETE call on item 100(#01) and CREATE call on item 100(#02).  After this you can do INSERT 200 to the uesr store.

    BTW - I am using #01 as the metadata id format just for illustration purpose ONLY and metadata Id is not exposed.

    Thanks.


    Leo Zhou ------ This posting is provided "AS IS" with no warranties, and confers no rights.
    Saturday, April 17, 2010 7:08 PM
    Answerer
  • Thank you L Zhou, realizing metadata id is different from "data key" definitely helps to understand the process much better! However would you elaborate on the difference between ModifyAndInsertRemoteItem and ModifyAndUpdateRemoteItem on ISimpleSyncProviderConstraintConflictResolver?
    Monday, April 19, 2010 5:01 PM
  • ModifyAndUpdateRemoteItem - When overridden in a derived class, renames the remote item so that it no longer conflicts with the local item name and updates the remote item in the local replica.
    ModifyAndInsertRemoteItem - When overridden in a derived class, renames the remote item so that it no longer conflicts with the local item name and inserts the remote item into the local replica.
    I think the difference is whether the remote item exists locally or not. If it exists - Update() is called, else - Insert(),
    Hope this helps.
    Adrian
    Monday, April 19, 2010 11:19 PM
  • So if I understood correctly for a store:

    Remote Store

    ========

    Item(#01)   "Name A"

    Item(#02)  "Name B"

    When you sync these two items into the store two paths will be taken:

    Item(#03) "Name B" -> ModifyAndInsertRemoteItem (because #03 doesn't exist)

    Item(#02) "Name B" -> ModifyAndUpdateRemoteItem (because #02 exist)

    Is this correct?

    Tuesday, April 20, 2010 5:14 PM
  •  

    I think the 2 conflict situation happens in following way.

    Store 1                                       Store 2
    itemA (constraint col: 100)             itemB (constraint col: 100)
    You will get a ModifyAndInsertRemoteItem when sync from 1 to 2,
      because itemA was never in store 2 before. You can change itemA's c-col to 101, later when sync back, itemA c-col in store 1 will be changed to 101.


    Store 1                                       Store 2
    itemA (constraint col: 50)               itemA (constraint col: 50)
                                                     itemB (constraint col: 100)
    itemA now updated to constraint col:100
    You will get a ModifyAndUpdateRemoteItem when sync from 1 to 2,
      because itemA is in store 2. You can change itemA's c-col to 101, later when sync back, itemA c-col in store 1 will be changed to 101.

    Tuesday, April 20, 2010 8:21 PM
    Answerer
  • So it would be very hard to deliberately create this update situation because item identifier is assigned by the framework (or metadata manager). For the code path to be hit both store has to have an item with same identifier by accident?

    Wednesday, April 21, 2010 8:34 PM
  • Right, if your constraint only exists for the primary key. However, if you have other constraint column, this will be easier to see.

     

    Thursday, April 22, 2010 6:16 PM
    Answerer