在NDB事务中读取数据存储区实体仅keys_only

如何解决在NDB事务中读取数据存储区实体仅keys_only

我对数据存储实体在ndb事务中读取有疑问。

我知道，当我们读取ndb事务内的实体时，该特定实体将被锁定，并且其他线程无法放置/更新/写入同一实体，因为这将导致争用错误。 完全有道理。

但是，当我们仅读取实体的密钥而不是事务内部的整个实体本身时，会发生什么情况？这可以通过在ndb.query（）。fetch（）中将 keys_only 标志传递为True来完成。 在这种情况下，实体会再次被锁定吗？

解决方法

Datastore documentation for Transaction Locks说：

读写事务使用读取器/写入器锁来强制隔离和可串行化。

它也没有提到任何在交易过程中使用keys_only的细节的情况。因此，我认为情况也一样。如果您认为自己仍然在读取数据，而忽略了数据，那确实是有道理的。

话虽这么说，也许这可以在Datastore中进行改进，甚至可以在文档中阐明。如果您愿意，可以考虑遵循此link。向Google打开功能请求以实施该功能。

,

通常，最好以保证交易性（可串行性）而不是实现细节的方式来考虑事务，在这种情况下，是读/写锁。实施细节（如何执行查询，锁定粒度，确切锁定的对象等）可以随时更改，而保证不会改变。

对于此特定问题，并假设Firestore当前以数据存储模式实施：为了确保可序列化性，事务T1中的仅键查询将锁定该查询检查的索引条目的范围。如果这样的查询返回了实体E的键K，那么在另一个事务T2中删除E的尝试必须删除所有E的索引条目，包括查询锁定范围内的索引条目。因此，在此示例中，T1和T2需要相同的锁，并且两个事务之一将被延迟或中止。

请注意，T2还有其他与T1冲突的方式：它可能还会创建一个与T1的查询相匹配的新实体（这将需要在T1的查询锁定的范围内编写索引条目）。

最后，如果T2要以某种方式更新（而不是删除）E，而该方式确实需要对T1的查询所检查范围内的索引条目进行任何更新（例如，如果查询类似于“从X中选择*”， = 5”，并且对E的更新不会更改其“ a”属性的值），那么T1和T2将不会发生冲突（这是一种优化-如果这两个事务确实发生冲突，行为仍将是正确的，事实上，对于“可能会冲突的“数据存储本地”数据库。