Thanks.
On Tuesday, January 20, 2015 at 12:53:25 PM UTC-2, Joshua Smith wrote:
>
> If you get by key, you are guaranteed to get the last thing you put there.
>
>
> https://cloud.google.com/appengine/docs/python/datastore/structuring_for_strong_consistency
>
> On Jan 13, 2015, at 11:04 AM, Julio Ot
If you get by key, you are guaranteed to get the last thing you put there.
https://cloud.google.com/appengine/docs/python/datastore/structuring_for_strong_consistency
> On Jan 13, 2015, at 11:04 AM, Julio Otuyama wrote:
>
> Does it work on two different connections (two different requests)? I s
Does it work on two different connections (two different requests)? I
suppose in the same connection the database may store a cache that can give
the correct visibility, but this could be lost with another connection. The
documentation says that there are two phases, the commit phase and the
ap
The only thing that is “eventually consistent” is queries. If you go and fetch
an item directly, you’re going to get the thing you sent to the db. Every time.
So the workaround is simply and reliable:
1. If you are just changing items, query just for keys, and then query those
keys to get the a
GAE HR is one step towards scalability, separating commit and visibility,
but one step back in usability. This separation creates a problem (the
"eventual consistency"?) that kills its use in some application designs.
Usually, I commit inside a http request and redirect to another page that
sh
