I want to get our wordology clear (let me know where I am going wrong): A Model in AppEngine is equivalent to a Table in SQL (or, if you like, it is equivalent to the Table Schema).
An Entity in a Model is equivalent to a Row in a Table. (so.. a Model is potentially a collection of Entities in the same way a Table is potentially a collection of Rows) Properties (of the Entities) in a Model are equivalent to Columns (of the Rows) in a Table. Maybe the confusion comes in with the wordage: "all of the index rows for that entity must be updated" What is an index row? I am assuming that an "index row" for a certain property is a row entry in BigTable that contains all index information for all Entities in the given Model that have that property defined. So, there would be an "index row" for the Month Property of your Stats Model defined above. And, when an Entity was inserted or Deleted for this Stats Model, the index row for Month would have to be rebuilt. I am assuming they can't do a diff.. because you have to grow the index.. there is a new Entity. If later on you updated a few properties of this newly inserted entity, then the datastore would know which properties were changed, and only update the indexes for the changed properties... since the index space has already been allocated for this new Entity in the appropriate Index Rows. I understand that I can be completely wrong on this.. but let me know where the flaw in my understanding of Entities, Models and Indexes might be. Thanks. On Nov 4, 4:08 pm, Stephen <[email protected]> wrote: > On Nov 4, 6:48 pm, Eli <[email protected]> wrote: > > > Stephen, > > > My thinking on this is.. > > > Say you have a Month Column.. and it has the default lexically sorted > > asc,dsc indexes on it. > > > My assumption is, when you insert a new row with a Month value > > defined, the entire index will have to be updated (no matter how many > > shards or tablets it's broken up into). > > No. One new entry will be added to the ascending index bigtable, and > one new row will be added to the descending index bigtable. > > > This is supported by this quote from the Index Building document you > > linked to: > > > "When an entity is created or deleted, all of the index rows for that > > entity must be updated." > > - By 'entity' they mean a single instance of an etity, i.e. a row, not > a 'type'. > > - And by 'all indexes' they mean index entries for all attributes of > that single entity, i.e. an entity with two integer attributes would > have four index entries created, 1 asc and 1 desc for each attribute. > > They are just trying to draw a distinction between when an entity > which is created or deleted, and when it is updated, which they cover > in the next sentence: > > "However, when an existing entity is updated, the datastore determines > the delta, i.e. the properties that were changed, and only updates the > index rows that include those properties." > > I guess this optimisation is worth mentioning in the docs because you > can't do an SQL-like: > > update Entity set attr_1 = 42 where key = 99. > > ...you can only overwrite all attributes, and so you may expect this > to trigger index updates for all attributes. But no, apparently this > is optimised out. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
