我的批写操作为快照侦听器返回了奇怪的延迟补偿结果。批处理可以完美地在数据库中执行写入操作，并且不会在客户端上产生错误，但是侦听这些文档之一的快照侦听器（在同一应用程序中）将返回奇怪的延迟补偿结果。批次：
example如果快照侦听器忽略let db = Firestore.firestore()
let batch = db.batch()
let timestamp = FieldValue.serverTimestamp()
batch.updateData([
"private.index.\(someId)": ["count": 0, "timestamp": timestamp]
], forDocument: db.collection("someCollection").document(uId))
batch.deleteDocument(db.collection("anotherCollection").document("\(uId)-\(someId)"))
batch.commit { (error) in
if let error = error {
print(error)
}
}
的返回值，则数据很好，因为它来自服务器（正确）。但是，如果快照侦听器允许延迟补偿的数据，我会得到：
hasPendingWrites来自服务器（和事务）的数据如下：
["count": 0, "t": <null>]]
没有理由时间戳为零。
另一个奇怪的是，如果我在事务中执行相同的任务，即使使用延迟补偿的数据也没有问题（这是正确的）。
["count": 0, "t": <FIRTimestamp: seconds=1586033607 nanoseconds=198000000>]]
批处理写入是否有时不能像事务处理那样完全正常工作，因此有时不能给出一致的延迟补偿结果吗？
答案 0 :(得分：1)
我最近写了一篇有关behavior of server timestamps的博客文章。它与批处理没有任何关系-只是普通的旧文档写入将显示相同的行为。您所看到的实际上是预期的行为。但是事务的行为有所不同，因为本地缓存不涉及事务行为，因为它需要与服务器完全同步才能成功（没有待观察的事务写入）。
如果您绝对需要尚未同步的快照中的时间戳，则应该不不带任何参数的getData()来获取快照中的数据。相反，您应该使用getData(serverTimestampBehavior)。您传递的参数：
为尚未设置为其最终值的服务器时间戳配置行为。
通过ServerTimestampBehavior的选项，您可以选择是否要估算，不估算（如现在所见，为零）或该字段的上一个值。听起来像您要估算。