Preventing the deletion and Re-establishing synchronization for deleted item/metadata RRS feed

  • Question

  • Hi,

    I am creating an application, which syncs data according the filter settings.

    Lets presume that Replica A has Metadata SyncId1 with creation/change knowledge (A:1/A:1) and it is synced to Replica B and created here as SyncId1 with (A:1/A1).

    According my applications bussiness logic, deletions made on Replica B must NOT be propagated back to Replica A, therefore Replica A should have it's record unchanged/undeleted and when FilterCallback() function allows -> subsequently propose it to Replica B as a missing data in a manner of "SaveItemChange.Create" to be restored in Replica B. I managed to do that in ScenarioNo-1, but failed in no-2:

    ScenarioNo-1. After item X deletion in Source B, Replica B enumerates SyncId1 as a deletion and syncs it to Replica A as a DeletionTombstone. Replica's A provider checks some Logic settings and understands that deletion must not be propagated to Source A, so it does NOTHING with item X in Source A nore with metadata SyncId1 in a ProcessItemDelete() of Replica A. Subseaqent sync cycles does not see any changes and takes no action (it is OK). But if application user decides that item previously deleted from Source B should be restored, I load Metastore of Replica B and such actions to force Replica B forget it EVER HAD a meta SyncId1:

    this.Metadata.RemoveItemMetadata(new List<SyncId>{SyncId1});

    After that I call synchronization process and GetChangeBatch finds in Replica A that it has SyncId1 that is absent in Replica B and propagates Change action as a Create - Item X is successfully re-created in Replica B. That's working if no changes have been made to Item X on a Source A before the deletion!!! (see scenario No-2.)

    ScenarioNo-2 :(.  After Item X is synced from Source A to B it is changed on Source B. Providers enumerate changes and lets say Replica B has knowledge SyncId1(A:1/B:5), accordingly, Replica A after sync gets SyncId1(A1:/B:5) too. And if from that point I try to repeat scenario No.1, I get no re-creation :( Even if Replica's B metastore has no meta with SyncId1, SyncKnowledge and ForgottenKnowledge has no records with SyncId1, SyncFramework can not determin that Replica B misses SyncId.

    The only difference in working and nonWorking scenarios I see that in first scenario Metastore A knows only this that SyncId1 was created on A, but in ScenarioNo-2 it already knows that it was created in A but changed on B!!!

    How can I force Replica A to forget it had a change from B? 
    Or maybe, what is correct way of dealing with such situations? What I'm I doing wrong?  Any advices are welcome!
    Monday, June 9, 2014 7:29 PM