I agree, the docs really should elaborate on this topic in general. 1) As I understand, it is because the updates within an entity group are strongly consistent, whereas updates across entity groups may not be. When you try to read the data with an ancestor, it will all be read from the same data center. If you read data from multiple entity groups, some of the entity groups may not be fully up-to-date.
2) First, there are no unique values in the datastore. The best way (I'm aware of) to achieve a unique value is to (in a transaction) 1) get a marker entity (or the 'real' entity) using a key you've built with your unique number, 2) if you don't get a result the value is unique, 3) if it was unique write an entity with the key back to the datastore. Alternatively you can use one entity group plus a query to achieve this, the process will be similar, just replace the get in step one with a query. For this type of use, you'll probably not see a lot of impact on read performance. Where it will impact you is write performance, you'll be limited to a few writes / second since everything is within one entity group. Hopefully a Googler will correct me if I've misunderstood or miscommunicated anything here. Robert On Wed, Jan 19, 2011 at 18:20, repairman9898 <[email protected]> wrote: > Hi, gae just came out w/ high replication datastore. The bad side effect is > that the data you insert into the datastore will not immediately become > consistent until after a few seconds in most cases called eventual > consistency. If you want to be able to query consistent data, then > according to the doc you have to insert the data w/ a parent key and query > using the key as ancestor. > 1) I understand the reason for eventual consistency i.e. because the > backend has to copy the data to all the database nodes to achieve high > replication hence the delay of consistency. But why is it if I insert an > entity w/ a parent key, then all of a sudden this problem of eventual > consistency goes away? The doc > (http://code.google.com/appengine/docs/java/datastore/hr/overview.html) doesn't > explain. How does the parentKey (ancestory) solves the problem? > 2) Let's say I have a table/entity called "socialsecurity" and > column/property is called "number". I chose to have high replication > datastore because it's mission critical. The objective is to insert UNIQUE > value into "number" property of the "socialsecurity" entity. The problem > is after I insert a value ABC, the datastore is not guaranteed to be > consistent, so if I do a look up to see if the next value (also ABC) is > already in the datastore I may get a false even though ABC is already in the > datastore but just not consistent yet. So according to the doc, I should > insert the entity w/ some parentKey then query w/ the parentKey as the > ancestor? how does it affect the read performance? since I don't > understand how ancestor key help w/ eventual consistency I couldn't even > speculate on the performance impact. > Any db guru can shed some light? > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
