Instead of changing db.Key's str encoding, one could change db.Key's __cmp__(self, o) returned cmp(str(self), str(o)). This wouldn't break any string keys in the wild or user code (which can't depend on how db.Key.__cmp__ works anyway, just that it does). However, I don't know if Google's internal code depends on how db.Key.__cmp__ works.
On Nov 1, 12:25 pm, ryan <[EMAIL PROTECTED]> wrote: > it's definitely possible to come up with a string encoding that > matches the internal key ordering. a naive encoding with the path > elements separated by slashes would work, e.g.: > > /Blog/My Blog/Post/My first post/Comment/3 > > where Blog, Post, and Comment are kinds, My Blog and My first post are > key names, and 3 is an id. > > it'd be difficult to change the existing string encoding now that it's > been used in the wild, though, since it would break string keys that > people have used in URLs, etc. we could change it in a new, opt-in API > version, or we could change it to accept the old encoding as well as a > new one. it's not a high priority, 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 [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 -~----------~----~----~----~------~----~------~--~---
