Jesse,
I believe this is a dangerous decision. The next sync will try to delete the record on the server.
A suggestion was made below to detect the situation and apply an Action of RetryWithForceRewrite. This is not, in my opinion, an entirely workable situation, or at least it is not if the filter applies to more than one table. I have a situation
where multiple tables are brought into filter scope because the filter clause is based on a foreign key. If this situation occurs, only the tables that have been updated since the last sync will be propagated to the client, and, if we use RetryWithForceRewrite
and not all tables have been updated (which I would presume is the default situation) then we will either hit a problem with FK constraints, or we will end up with partial replication of a set of related records.
My solution is different. I am detecting the situation where records come into filter scope, and I am requiring that the client sync, delete the scope and reprovision (which is a good solution for us because the overhead is so much less than synchronizing
without a filter). The issue is that I want to be able to ignore this LocalCleanedUpDeleteRemoteUpdate conflict, and I cannot
- RetryWithForceRewrite will insert the records locally which can result in a partial update per the dsicussion above
- RetryApplyingRow, which looks like it should do the right thing, does not try to apply the row "one more time". It tries to do it indefinitely rather than once, which has no effect, but is just really annoying and I dont really like infinite loops
in my production code
- Continue inserts a tombstone record which will cause a delete on the server on the next sync
- RetryNextSync is the best bet since it defers the next failed retry to the the next sync
It would be great if there was a way to simply ignore this sync situation.
Nick Caramello
