Firestore延迟补偿快照返回在批处理和事务之间不同

Question

我的批处理写入为快照侦听器返回了奇怪的延迟补偿结果。批处理在数据库中完美地执行写入，不会在客户端上产生错误，但侦听其中一个文档的快照侦听器(在同一应用程序中(会返回奇怪的延迟补偿结果。批次：

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>]]

时间戳不应该为零。

同样奇怪的是，如果我在事务中执行相同的任务，即使使用延迟补偿的数据，也不会出现问题(这是正确的(。

db.runTransaction({ (trans, errorPointer) -> Any? in
trans.updateData([
"private.index.(someId)": ["count": 0, "timestamp": timestamp]
], forDocument: db.collection("someCollection").document(uId))
trans.deleteDocument(db.collection("anotherCollection").document("(uId)-(someId)"))
return nil
}) { (_, error) in
if let error = error {
print(error)
}
}

批处理写入有时会不会产生一致的延迟补偿结果，因为它们的工作方式与事务不同吗？

Answer 1

我最近写了一篇关于服务器时间戳行为的博客文章。它与批处理无关——只是普通的旧文档写入将显示相同的行为。你所看到的实际上是预期的行为。但是事务的行为不同，因为本地缓存不参与事务行为，因为它需要与服务器完全同步才能成功(事务中没有待处理的写入操作(。

如果您在快照中绝对需要尚未同步的时间戳，则应不要使用不带参数的getData((来获取快照中的数据。相反，您应该使用getData(serverTimestampBehavior(。你通过的论点：

配置尚未设置为最终值的服务器时间戳的行为。

ServerTimestampBehavior的选项允许您选择是要估计值、none(无，如您现在看到的(还是字段的上一个值。听起来你想要一个估计。