locked
initial synchronization and "joining" two objects with the same identity RRS feed

  • Question

  • I have written an anchor provider that operates in a hierarchy.  Given two instances of the provider, it happily synchronizes between two stores, if the replica starts off empty and all items are created by the replication process. If I try to sync the stores after the fact , any confilcting data during the initial sync will of course raise a conflict. What I want to do is verify the replica and then tell the framework that the item metadata is ok as is (the itemfield dictionary that is  constructed from the replica data). If I return the same field dictionary to the sync framework, it will keep the item in conflict , If I modify the itemfield data used for the identity field, then the sync framework is happy, but I have to store the modification on the replica item in the store and I dont want to have to do that.

    Any insight would be appreciated
    Robert G
    Monday, March 1, 2010 4:56 PM

Answers

  • Out of curiosity, where is the Guid coming from?  If you're syncing files, or something like that where the identity can be determined by a file name and a path, a mapping to a Guid is not necessary, but I don't know the exact nature of your data.

    In general, since providers report constraint conflicts rather than the framework, you should merge the data so that your constraint detection logic is satisfied. That could be what is happening when you modify one of the other fields, but it really depends on how you're doing constraint detection.

    Aaron
    SDE, Microsoft Sync Framework
    Wednesday, March 10, 2010 8:43 PM
    Answerer

All replies

  • Hello Robert Ginsburg,

    If I am understanding your question correctly, you are creating an item that is identical in metadata (field dictionary) and want the sync framework to treat them as

    same item as one already in sync.

    To describe the problem, identity field, by design, has to be unique. If another item with same identity field is reported to framework, it does not perceive them as

    same item, but as different item with constraint conflict on primary identity.

    This is a suggestion. One way to resolve this issue is to merge the two items's identity into a single item.

    Here is a brief description on how to handle constraint conflict.

    Have the provider implement ISimpleSyncProviderCustomConflictResolver.

    During insert / update / delete item call, report constraint conflict with the incoming item using RecoverableErrorReportingContext.

    Then, on ItemConstraint event, choose resolution to Merge.

    The framework will then call MergeConstaintConflict method on your provider which implements ISimpleSyncProviderCustomConflictResolver.

    MergeConstraintConflict should do the following:
    - merge the two items into a single item
    - this implies that the losing item will be deleted within this call

    Hope this helps.

    Thanks,

    Patrick


    Tuesday, March 2, 2010 12:15 AM
  • Thanks for the comments, and the situation that you describe is exactly what I am trying to do, the confusion I am experiencing is what to return in the updatedKeyAndVersion field dictionary from MergeConstraintConflict. If I have merged the data fields but make not changes to the identity field, then the the item is always treated as conflicted. What I want to do is signal to the sync framework that the conflict has been resolved, but the resolution just did not change any of the item keyandversion values. the reason it did not change was because it had been previoulsy synchronized. I suppose I could "tickle" the item and refresh one of the version fields but that seems a bit odd.

    -Robert

     


    Robert G
    Tuesday, March 2, 2010 12:37 AM
  • Hello Robert,

    Merge implies that you now have a single item. Provider code must explicitly delete the other item.

    By design, one cannot "trick" framework to think that an item is same item by creating another item with same identity field.

    i.e. same item cannot be created in two different locations.

    Internally, the framework is aware of the fact that the two seemingly identical items are in fact different items.

    This will cause constraint conflict during sync at which you have the following choices:

    - Merge the two into same item
    - Keep the remote item and delete the local item
    - Keep the local item and delete the remote item
    - Keep both items by modifying the local item before letting remote item to come through

    Hope this helps.

    Thanks,

    Patrick
     

    Tuesday, March 2, 2010 6:36 PM
  • Hi Patrick,

    I definitely want to merge the two items into the "same item". The scenairo is that we had a good sync before, and for some reason we no longer have the meta data so we are "re synchronizing the system". In this scenairo I want to handle the merge, but since the item is the same, the metadata created by it will be the same as the metadata that caused the conflict. If I return that same metadata that caused the conflict in updatedKeyAndVersion  (in the MergeConstraintConflict call) then the item stays in conflict. I have discovered that if I leave the identity field alone, but change any of the other items, it will clear the conflict so I have resorted to this as a technnique, I am simply updated the last change date time stamp on the item in conflict, however this seems like the wrong way to handle it. To clarify, (just to make sure I have made the problem clear). I am able to detect the conflict during an insert for the first sync, and record the constraint error, the framework is set to merge and the MergeConstraintConflict call is made. If I return the same ItemFieldDictionary data that caused the conflict (which was collected during enumeration) the conflict persists to the next session and on, until I modify one of the values in the ItemFieldDictionary. Since the ItemFieldDictionary represents the actual data, I have to modify the source data to make that work , I have resorted to updateding the last write time but I dont see why I cant just "join" them together in the MergeConstraintConflict call.

    BTW Thanks for the responses !!


    Robert G
    Tuesday, March 2, 2010 9:12 PM
  • Hi Robert,

    Sorry for the delayed response.  Can you describe the fields that you're passing in the ItemFieldDictionary? 

    Aaron
    SDE, Microsoft Sync Framework
    Tuesday, March 9, 2010 8:02 PM
    Answerer
  • Aaron,

    The Identity field is a guid, in addition there are two string fields representing a name and a path and a Int64 that represents a time stamp for the last change.

    -Robert
    Robert G
    Wednesday, March 10, 2010 9:44 AM
  • Out of curiosity, where is the Guid coming from?  If you're syncing files, or something like that where the identity can be determined by a file name and a path, a mapping to a Guid is not necessary, but I don't know the exact nature of your data.

    In general, since providers report constraint conflicts rather than the framework, you should merge the data so that your constraint detection logic is satisfied. That could be what is happening when you modify one of the other fields, but it really depends on how you're doing constraint detection.

    Aaron
    SDE, Microsoft Sync Framework
    Wednesday, March 10, 2010 8:43 PM
    Answerer
  • The primary store is actually active directory, and the guid is the permanant guid of the object.

    What I discovered is that in the merge  I was updating the timestamp of the object i conflict,  which essentially shows up in the next sync pass as an update. I made a change such that the item was only updated if the values were different, so that I do get the conflict twice, but I can detect the condition the second time and leave the source change alone, and then everything seems to be ok.


    Robert G
    Thursday, March 11, 2010 10:52 AM
  • Robert,

    Glad you were able to find a solution.  I'll take the feedback that we can be better in our documentation (and perhaps in code) to make this more seamless moving forward.


    Thanks,

    Aaron
    SDE, Microsoft Sync Framework
    Monday, March 15, 2010 8:10 PM
    Answerer