Hi Ryan, posting to the group since it could be interesting for others, as you suggested.
On Sun, Mar 8, 2009 at 12:26 AM, Ryan Barrett <ry...@google.com> wrote: > On Sat, 7 Mar 2009, Waldemar Kornewald wrote: > >> is there a reason why entities can have a key id or a key_name? Would >> it be so much less efficient if there were only key_names? > > ids are nice because we allocate them for you. they parallel the id sequence > and auto increment features that many relational databases have. managing a > primary key namespace actually takes some work, and often you don't care > what your primary keys are, so ids tend to be useful. > > (incidentally, performance for id and key name are more or less identical.) 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). Couldn't you allow for overriding ids while at the same time assigning free ones automatically? 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). >> What major changes do you plan for the next Model API? > > hmm, i'm not sure! i don't think we have any major changes planned. > honestly, it's not as high a priority for us right now as other app engine > features on the roadmap, like the new runtime language and background > processing. > >> Could you please provide an official low-level API for checking >> whether I'm in a transaction (i.e., an alternative to >> _CurrentTransactionKey())? >> >> Could you please provide an API for opening and closing a transaction >> (instead of only run_in_transaction)? Those will be necessary for >> porting Django's Model API. > > interesting! these are definitely both reasonable feature requests. we > offered run_in_transaction originally because we often need to retry > transactions due to contention, and we need a lambda to do that. we could > definitely offer another API with manual begin/commit/rollback calls, but it > would return TransactionFailedError somewhat more often. > > regardless, feel free to file feature requests for these, if there aren't > already! http://code.google.com/p/googleappengine/issues/detail?id=1131 Bye, Waldemar Kornewald --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
