我有一个名为 SignupTokens 的模型，当用户从我们的聊天机器人确认他们时，我们使用 isUsed = True 更新实体，更新实体后，如果我们使用 isUsed = False 查询特定同一电子邮件的未使用令牌，那么一段时间结果是甚至已经用 True 更新了 isUsed 标志。每当我们遇到这个问题时，我们都会仔细检查数据存储实体是否单一。
SignupTokens.gql("where isUsed = :1 and email = :2",False,email).get()
我们已经尝试过使用_cache = False like
SignupTokens.gql("where isUsed = :1 and email = :2",False,email).get(use_cache=False)
请让我知道任何人对此有任何想法。
【问题讨论】：
标签： python google-app-engine google-cloud-datastore gql
这很可能不是 ndb 缓存问题，这是由于 eventual consistency 而导致的预期数据存储行为：从实体的 isUsed 属性设置为 True 到与您的索引对应的索引需要一些时间查询会相应更新。
在更新索引之前，查询结果不会反映更改。
【讨论】：
keys_only，然后通过键查找（始终保持一致）从查询结果中检索实体的实际内容，并检查isUsed 实际值。
key = SignupTokens.gql(..).get(keys_only=True)和ndb.Key(key).get()？
key.get()，或者更有效的是ndb.get_multi(keys)（一次最多500个键）。
keys = self.query(ndb.AND(self.isUsed == False, self.email == email)).fetch(keys_only=True) 和 obj = keys[0].get() 仍然返回某个较旧的结果。
正如@Dan 所建议的，这很可能不是ndb 缓存问题。这是您在连续读写同一个实体组时引起的问题。这是一种数据存储行为，基本上是由 datastore contention 和 eventual consistency 引起的。
有一些方法可以避免这种情况。
使用key 进行查询。每当您尝试通过其键读取对象时，它都是strongly consistent。所以，在你的情况下，我建议存储你正在更新的对象的密钥，如果可能的话，然后读取它并执行你想要的操作。
另一种方法是使用 NDB 异步操作。在此处查看相关documentation。
您可以尝试提供可以帮助您的延迟，但应以足以更新对象的方式提供延迟。
希望这能回答你的问题！！！
【讨论】：