Thanks for the answer. The results I am seeing are not because of ndb caching as it does not cache queries by property.
I imagine that the datastore eventual consistency has always been fast enough so the required indexes are updated by the time I run a put, then get operation making the subsequent query by property always work so far in testing. Thanks for making it clear that there is no technical reason/guarantee to rely on this. On Sunday, July 20, 2014 11:36:49 PM UTC+1, Jeff Schnitzer wrote: > > The answer to your question is no. > > Queries are eventually consistent because index changes are replicated > between datacenters asynchronously and queries are served by any > datacenter. Strongly consistent get-by-key operations require a quorum of > datacenters; they have no effect on query index replication. > > Note that while get-by-key is strongly consistent by default, you can > explicitly request an eventually consistent get-by-key. Since it returns > the first result as-is (without waiting for a quorum), it is quite a bit > faster. > > Also: You may be experiencing cache behavior; ndb caches at both session > and memcache level. > > Jeff > > > On Fri, Jul 18, 2014 at 2:17 PM, Dan <[email protected] <javascript:>> > wrote: > >> Apologies Chad, I didn't make myself clear. I was using Python ndb >> terminology with 'get', 'put' and 'query'. >> >> What I want to clarify is if an entity will always be returned from a >> fetch by kind if it has previously been fetched by key. >> >> This is what I experience in testing. I also remember reading that an >> entity's indexed properties are written to their respective indexes, if not >> done already, on its first fetch by key. >> >> Therefore can you effectively get strong consistency by adding a fetch by >> key after adding an entity to the datastore? >> >> Example 1: >> 1) Put entity A. >> 2) Query for entity A by kind. // This does not always return entity A >> due to the eventual consistency nature of the datastore. >> >> Example 2: >> 1) Put entity B. >> 2) Fetch entity B by key. >> 3) Query for entity B by kind. // Always appears to return entity B. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/google-appengine. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
