Much simpler would be to always declare a parent when creating the original object. Since the parent need not exist, it might be possible to do this without even creating the parent (the Model docs say you can declare a parent using a Key object - can you create a Key object without creating a model to match it?).
Here's the scheme: Pick a random key for the parent. Instantiate a Key object Declare it as parent when creating your original object. Whenever you need to re-create the object, just do it in a transaction. What about uniqueness of the parent? Well, since you only care that you've deleted/created the single entity, it doesn't even matter if the parent is unique - just that it's unlikely that another such transaction is happening at the same time. If you choose a long enough random parent key, this devolves to the birthday attack.... basically, just make it a long string, since it doesn't much matter anyway. If you *do* have to create the parent object first, just create it, then delete it once the desired child object exists. Costs a bit more in Datastore time, but still solves the problem. On Oct 27, 8:47 pm, yejun <[EMAIL PROTECTED]> wrote: > The new object's key path will get longer and longer and eventually > over the limit. Also you need to know all its previous keys to be able > to retrieve it by key name. > > I think the best practice to change primal key is create an > intermediate transaction log object which belongs to old entity group > and point it to the possible new key. Then do the actual create then > delete the intermediate transaction log object. > > On Oct 27, 7:30 am, Jon McAlister <[EMAIL PROTECTED]> wrote: > > > You are correct that the best way to get around key restrictions on > > starting with digits is to add some string prefix. However, the > > problem with this code is that you also need to take care when > > modifying the uid for a user. There is no way to change a datastore > > key. Instead, you would have to create a new entity (with the new uid) > > and delete the old one (with the old uid). And, since you're not using > > entity groups here it won't be possible to do that transactionally. To > > get around this, you could make the new entity a child of the old > > entity and that would work (it's perfectly to delete a parent entity). > > > On Oct 25, 7:30 pm, Alexis Bellido <[EMAIL PROTECTED]> wrote: > > > > Hello everybody, I needed to store some information about my users (I > > > don't need to use Google accounts) and created a model called FbUser, > > > each entity in the model is a fbuser and each fbuser has a unique user > > > uid, a field I call 'uid'. > > > > A uid can't appear more than once in the datastore but it could > > > eventually change for a user, so it's not inmutable. It can't be used > > > directly as a key_name because it always starts with a number, in fact > > > is always a ten digit number. > > > > I want to make sure that I only store unique uid's in the datastore so > > > I thought about Model.get_or_insert: > > > >http://code.google.com/appengine/docs/datastore/modelclass.html#Model... > > > > and found this suggestion by Dado (thanks a lot for it): > > > >http://groups.google.com/group/google-appengine/browse_thread/thread/... > > > > I implemented it for my case like this: > > > > class FbUser(db.Model): > > > """ > > > You can then call FbUser.get_or_insert_by_uid('foo') and get back an > > > FbUser instance with that unique identifier (it gets created if it > > > does not yet exists).Model.get_or_insert is automatically wrapped in > > > a transaction > > > """ > > > > uid = db.StringProperty(required=True) > > > > @staticmethod > > > def get_or_insert_by_uid(uid): > > > # prefix with unique identifier to qualify and avoid beginning > > > with digits, which datastore does not accept > > > key_name = 'uid:'+uid > > > return FbUser.get_or_insert(key_name, uid=uid) > > > > And then I can 'get or create' a fbuser with uid '123' using this: > > > > FbUser.get_or_insert_by_uid('123') > > > > I've tested and it works but I want to be sure if this is the right > > > way of doing it. What do you think? > > > > Thanks! > > --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
