我有一个名为lineItems的数据存储区实体，它由要开票的各个订单项组成。用户查找订单项并将采购订单编号附加到订单项。它们显示在网页上，用于创建发票。
我会显示用于获取实体的代码，但我认为这根本不重要，因为几个月前我使用托管虚拟机时也发生了几次，代码完全不同。 （我之前使用的是objectify，现在我正在使用数据存储区API）。简而言之，我目前只使用StructuredQuery.setFilter（new PropertyFilter.eq（“POnum”，ponum））。setFilter（new PropertyFilter.eq（“Invoiced”，false））; （这是伪代码，你不能做两个.setFilters这样。真正的代码接受一个PropertyFilters列表并正确创建一个复合过滤器。）
今天早上发生的事情是管理员创建了发票，除了两条线以外的所有线都在发票上。代码从未提取过两行，这些行卡在“创建发票”部分。
管理员只需为给定的采购订单编号再次创建发票，但第二次DID拿起剩余的两行并创建第二张发票。
请注意，实体是在大约24小时之前（当她为其分配采购订单编号时）创建/编辑的，因此他们在数据库中待了很长时间。 （我检查了我的日志）。这不是刚刚创建它们的情况，然后尝试在短时间内访问它们。它也不是未能更新实体的情况 - 代码在第3方会计包中创建发票，而它们根本就不存在。在创建发票成功后，然后使用“invoiced = true”更新所有实体并将其写入数据存储区。因此，会计程序中未在发票上的行是未在数据存储中更新的行。 （这不是一个“智能”检查，它不会逐行检查。它只是检查发票创建是否成功，然后更新它在内存中的所有实体。）
据我所知，数据存储区根本没有返回第一次匹配查询的所有实体，但第二次没有返回。
大约有40'000个lineItem实体。
哪些条件可能导致数据存储区提取随机无法获取满足StructuredQuery搜索参数的所有实体？ （请注意，在现已弃用的Managed VM体系结构上使用Objectify时，这也发生了两次。）如何阻止这种情况发生，或检查是否发生了这种情况？
答案 0 :(得分：1)
您可能会看到最终的一致性，因为您没有使用祖先查询。