Azure 移动应用服务客户端如何处理孤立记录？

Question

我正在使用 Azure 移动应用服务。我正在使用软删除和增量同步功能。

我遇到了一个有趣的边缘案例：

1. 将新记录插入本地数据库
2. 推送
3. 记录在后端被删除。可以通过使用client.GetTable<T>().DeleteAsync(foo)而不是client.GetSyncTable<T>().DeleteAsync(foo)直接删除它来模拟客户端
4. 本地数据库现在比远程数据库多一条记录
5. 再次推送

我以为最后一次推送会在远程数据库上重新创建记录，但事实并非如此 - 这是令人惊讶且非常非常棒的结果，因为这是合乎逻辑的结果！

我不明白的是，为什么？客户端如何知道不推送该孤立记录？

（是因为我从客户端执行了删除操作吗？所以在生产中，当我们的后端系统删除该记录时，客户端会推送它吗？）

编辑，抱歉我没有正确解释：
我的意思是我们有后端系统，它可以直接在后端数据库上执行删除（他们不知道也不关心远程客户端）。我把上面的第 3 点放在上面，就像从客户端本身做的“hackish”方式一样。无论如何，在这种情况下，客户端上会有一个孤立的记录。发生这种情况并执行推送时，客户端是否会尝试在后端重新创建该记录 - 因为它不知道后端已将其删除？

Answer 1

软删除是客户端知道删除“孤立”记录的方式。换句话说，服务器实际上并没有删除记录，而只是标记了已删除的标志。进行离线同步的客户端会在拉取操作中获取已删除的记录，并从本地存储中删除这些记录。 （他们通过在请求中添加 __includedDeleted=true 标志来做到这一点。）

如果客户端更改了删除的记录并且您正在使用冲突处理（通过在客户端上具有版本字段），那么更新将通过常规冲突处理机制被拒绝。

Answer 2

当您创建一个同步表时，会在本地 SQLite 数据库中创建两个表 - 实际表和一个“待处理的操作”表。当您执行 SyncTable().DeleteAsync() 时，会从实际表中删除记录，并在“待处理操作”表中放置一个条目以删除后端的记录。当你执行 PushAsync() 时，挂起的操作表用于发送相同的 在线案例中会发送的请求。

还有一些比这更复杂的地方，但这是正在发生的事情的基本要点。

如果您有权访问底层 SQLite 数据库（例如，您在 Windows 上运行 UWP 应用），那么您可以检查底层 SQLite 数据库以了解实际发生的情况。