Stay organized with collections Save and categorize content based on your preferences.
Data consistency levelsDatastore queries can deliver their results at either of two consistency levels:
In an eventually consistent query, the indexes used to gather the results are also accessed with eventual consistency. Consequently, such queries may sometimes return entities that no longer match the original query criteria, while strongly consistent queries are always transactionally consistent.
Datastore query data consistencyQueries return their results with different levels of consistency guarantee, depending on the nature of the query:
Fetching an entity by key, which is also called "lookup by key", is strongly consistent.
Setting the Datastore read policyTo improve performance, you can set the Datastore read policy so that all reads and queries are eventually consistent. (The API also allows you to explicitly set a strong consistency policy, but this setting will have no practical effect, since non-ancestor queries are always eventually consistent regardless of policy.)
You can also set the Datastore
call deadline, which is the maximum time, in seconds, that the application will wait for Datastore to return a result before aborting with an error. The default deadline is 60 seconds; it is not currently possible to set it higher, but you can adjust it downward to ensure that a particular operation fails quickly (for instance, to return a faster response to the user).
To set the Datastore read policy and call deadline in Python, you pass them as arguments to the
run()
,
get()
,
fetch()
, and
count()
methods of class
Query
or
GqlQuery
. For example:
for result in Employee.all().run(limit=5,
read_policy=db.EVENTUAL_CONSISTENCY,
deadline=5):
# Body of iterative loop
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-08-07 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["Datastore queries operate at two consistency levels: strongly consistent, which guarantees the freshest data but may take longer, and eventually consistent, which is generally faster but might return stale data."],["Ancestor queries, which occur within an entity group, are strongly consistent by default but can be made eventually consistent by adjusting the Datastore read policy, whereas non-ancestor queries are always eventually consistent."],["Fetching an entity by key, also known as \"lookup by key\", provides strong consistency in retrieving data."],["The Datastore read policy can be set to ensure all reads and queries are eventually consistent, optimizing performance, and while a strong consistency policy can be set, it has no effect on non-ancestor queries, as they remain eventually consistent."],["The Datastore call deadline, the maximum time an application waits for a result, defaults to 60 seconds but can be reduced to ensure faster operation failures, thus allowing the possibility of faster user responses."]]],[]]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4