> we'd love to provide operations for advanced users to manage the id > namespace, e.g. NextId(), SetNextId(), and ReserveIds(), which would all take > a root entity as their argument.
I assume that one of those operations allows programmers to assign the id to a db.Model instance for a new entity. I read that as saying that the ids that can be manipulated would be wrt a given root. (I'm surprised that it's a root entity and not a root key, but that's not why I'm commenting.) I understand why you're considering doing that, but it would also be nice to have similar operations wrt "no root". I don't always have a reasonable way to name the root for a set of entities that I want to create atomically. For such roots, auto assigned ids are perfectly acceptable. However, since I currently don't get the id until after the put, I can't use a single put to do the root and the children without naming the root. Yes, I can wrap two puts, one for the root and a second for the children, into a transaction, but if I also want the root to contain the children's keys, I can't get their names until after the put that sets the root's id, which means that I need to put the root entity twice, the second time with the children's names, and I can't do that in a transaction. On Mar 8, 5:23 pm, ryan <ryanb+appeng...@google.com> wrote: > Waldemar Kornewald wrote: > > > I'm not against key ids in general. The problem with ids in App Engine > > is that they can't be set manually which means backups become much > > more difficult and when restoring a backup (or converting data from > > SQL) URLs have to be changed (because the id can't be retained). > > absolutely, we agree. > > > Couldn't you allow for overriding ids while at the same time assigning > > free ones automatically? > > definitely! we've considered this internally for a while. we'd love to > provide operations for advanced users to manage the id namespace, e.g. > NextId(), SetNextId(), and ReserveIds(), which would all take a root > entity as their argument. > > it's not a high priority for us right now, but we would like to do it. > as usual, feel free to file a feature request, or repurpose the one > you filed,http://code.google.com/p/googleappengine/issues/detail?id=1003 > . > > > Alternatively, would it be possible to configure models such that the > > datastore assigns an unused key_name instead of an id? Is there really > > such a huge performance problem with that? I'd accept it any time > > because the price of using key ids is just too high for us (it could > > be seen as some kind of vendor lock-in). > > this would be backward incompatible, since most existing entities use > ids, so it's more unlikely. migrating would be doable, but painful. > we're definitely interested in the id managament calls described > above, though! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
