python - 使用后端 NDB 的 GAE put_multi() 实体

Question

我正在使用后端通过 ndb.put_multi(list_of_entities) 编写多个实体。

我遇到的问题是，在此之后，如果我进行查询，我将得不到任何结果。如果我设置一个 sleep 定时器，例如 1 秒，我就可以读取我刚刚编写的实体。

例如:

class Picture(ndb.Expando):
    pass

class Favourite(ndb.Expando):
    user_id = ndb.StringProperty(required=True)
    pass

#...make lists with Picture and Favourite kinds
entities = favourites
entities[1:1] = pictures
ndb.put_multi(entities)

favourites = Favourite.query().filter(Favourite.user_id == user_id).fetch(99999, keys_only=True)
logging.info(len(favourites)) #returns 0 in dev_appserver why?

首先假设问题与缓存有关。 但是:

阅读 NDB Entities Operations on Multiple Keys or Entities :

Advanced note: These methods interact correctly with the context and caching; they don't correspond directly to specific RPC calls.

阅读 NDB Caching

The In-Context Cache

The in-context cache persists only for the duration of a single incoming HTTP request and is "visible" only to the code that handles that request. It's fast; this cache lives in memory. When an NDB function writes to the Datastore, it also writes to the in-context cache. When an NDB function reads an entity, it checks the in-context cache first. If the entity is found there, no Datastore interaction takes place.

Queries do not look up values in any cache. However, query results are written back to the in-context cache if the cache policy says so (but never to Memcache).

嗯，我迷路了。一切似乎都很好。即使从控制台查询我得到了正确的总和，但从来没有在同一个处理程序上，无论什么功能等。

我唯一注意到的是，当等待 time.sleep(1) 时，我会得到正确的结果。因此，这与 ndb.put_multi 可能未同步完成或未同步完成这一事实有关。好迷茫....

Answer 1

早上头脑清醒总好过晚上头晕目眩。

谢谢大家的评论。问题解决了。你以正确的方式引导我回答我的问题:

我使用祖先查询来正确获取结果。值得一提的是以下几点

Understanding NDB Writes: Commit, Invalidate Cache, and Apply

The NDB function that writes the data (for example, put()) returns after the cache invalidation; the Apply phase happens asynchronously.

这意味着在每次放置之后，应用阶段可能尚未完成。

并且:

This behavior affects how and when data is visible to your application. The change may not be completely applied to the underlying Datastore a few hundred milliseconds or so after the NDB function returns. A non-ancestor query performed while a change is being applied may see an inconsistent state (i.e., part but not all of the change). For more information about the timing of writes and queries, see Transaction Isolation in App Engine.

还有一些关于读取和写入之间一致性的信息，取自 Google Academy Retrieving data from the Datastore

Google App Engine's High Replication Datastore (HRD) provides high availability for your reads and writes by storing data synchronously in multiple data centers. However, the delay from the time a write is committed until it becomes visible in all data centers means that queries across multiple entity groups (non-ancestor queries) can only guarantee eventually consistent results. Consequently, the results of such queries may sometimes fail to reflect recent changes to the underlying data. However, a direct fetch of an entity by its key is always consistent.

感谢@Paul C 的不断帮助，感谢@dragonx 和@sologoub 帮助我理解。