On Dec 20, 11:14 pm, Thomas Johansson <prenc...@gmail.com> wrote: > > Is this to be interpreted as getting the following, in order, more or > less? (where the ID/Key is in square brackets) > > /Image[42] > /Image[127841] > > /Thread[10]/Post[42] > /Thread[10]/Post[127841] > > E.g. the ID is ever increasing, but only for the current fully > qualified path?
correct. > Can we ever experience inserting a record that will have a lower ID than the > previous? the others beat me to this answer. :P if the rest of the path is identical, then it's uncommon, but definitely possible. > Forgot to ask; How does the key fit into the hierarchy, compared to > the key_name & id? i'm not sure i understand this question. a key is composed of app id and the full path to the entity. key names and ids are components of paths. feel free to follow up if that doesn't answer the question. On Dec 23, 10:44 am, Andy Freeman <ana...@earthlink.net> wrote: > That's a curious comment. It suggests that ids may be reused if > there's another difference in the path. correct. for example, each of these keys is valid and points to a distinct entity: /Post[1] /Post[1]/Post[1] /Post[1]/Post[1]/Post[1] /Post[1]/Thread[1] /Thread[1] /Thread[1]/Post[1] /Thread[1]/Post[1]/Thread[1]/Post[1] /Thread[1]/Post[1]/Post[1]/Thread[1] > However, combining that with the statement that there's no reuse for a > given path is interesting because there's no obvious place for the > datastore to keep track of what ids it has used. under the covers, each entity group has its own id namespace that's used for non-root entities. root entities have their own per-app id namespace. both namespaces are independent of kind and path hierarchies (apart from the root entities, since they define entity groups). that means that in practice, every id-based root entity has an id that's across all other root entities, and every id-based non-root entity has an id that's unique across all other entities in that entity group. this is all just implementation details, though! we don't have any plans to change id allocation right now, and it's unlikely that we will, but the only hard uniqueness guarantee we provide is that the full path is unique. the upshot of all of this is that you generally want to use full keys whenever possible. bare ids or key names are generally only interesting or useful when the rest of the path is held constant, including the kind of the entity in question. that's the only way to guarantee the key names or ids will be unique. > Yes, one can store an indicator of what ids have been used (such as > the last id used) with an entity group, but what happens to that > indicator when the entity group goes away? If it is destroyed and > then recreated when the entity group is recreated, how does the id > allocator avoid previously used ids? good question! per-entity-group id namespaces currently live forever. if all of the entities in a given entity group disappear, and then the entity group later reappears, ids for new entities in that group will not be reused. this is another implementation detail, though, not a hard guarantee! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
