On Monday, 1 August 2011 02:30:11 UTC+1, Nick Johnson (Google) wrote: > > In the absence of cookbook examples, I've concluded >> >> - I can pre-allocate a range of IDs for a given class using >> db.allocate_ids(), but as individual keys encode the id and the parent >> instance (if any) then I can't convert these pre-allocated IDs into >> pre-allocated Keys if I may be using parent objects. >> >> False - see above. >
Between your answer and Stephen's, I think I must have phrased this bit poorly, so let me try again. I'm allocating IDs anticipating the client later creating instances of a class where different instances will have different parent objects that I can't predict at the time of allocating the IDs. Thus, allocating IDs is the best I can reasonably do in advance of sending them to the client, whereas if I was allocating IDs for objects which I knew would always have no parent, or always the same parent, then I could actually convert all the pre-allocated IDs into pre-allocated Keys (and thus leave the client logic handling Keys as it was before I started looking at pre-allocation). For example, I've got Vehicles and Garages, and I always create a Vehicle with a parent object of the Garage where it was first kept, but Garages themselves never have a parent. The client code includes logic to create new Vehicles and create new Garages, so I can't create Vehicle Keys in advance, as the user create a new Garage and then create a Vehicle for that new Garage (unless I get very wasteful of keys by generating enough to cover a load of possibilities etc). So instead I pre-allocate Garage IDs and Vehicle IDs(*) and let the client work with IDs only - when the client sends the details to the server of what it has made, I'll create the keys with the appropriate parents. Garages (in this poor example) have no parent objects, so I could actually convert the pre-allocated IDs into parent-less Keys and give this to the client to use as it sees fit, but it's easier to maintain one set of logic alone for both data types. [(*) - Stephen's making the point that I can simply allocate one range of IDs and use these for new Garages or new Vehicles as appropriate. I appreciate the info, and if I had hundreds of types of objects then I may look at that, but for now I'm happy to allocate a range for each type] Now when a client wants to update a Vehicle, it's only holding the ID, not the Key, but it knows the ID of the garage too, so it actually sends a request like "change the colour of Vehicle 1234 which happens to belong to Garage 6789", because even though there's only one vehicle with an ID of 1234, the backend needs to actually look up the Garage object to be able to call Vehicle.get_by_id() with the correct parent- it can find the Garage via Garage.get_by_id(6789, parent=None). But calling Vehicle.get_by_id(1234) without specifying the correct parent wouldn't find the object (whereas with Keys you can look up an object by itself as the Key encodes the parent). Nick, thanks for confirming my other assumptions. >> - I'll implement a new model base class for all db.Model derived >> classes, that defines a new optional "id" parameter and constructs the >> correct key (my python knowledge of the constructs is bit green, so I >> think >> this does what I expect - kind() is a reserved but undocumented instance >> method that looks safer than using __name__ by looking at the SDK source) >> >> You can do this if you want, but it's purely convenience. Don't override > the constructor, create a class method instead. The constructor is used to > reconstitute existing entities from the datastore in addition to creating > new ones, so overriding it correctly is difficult. > Ah, that's just the kind of nugget that I was hoping for. OK, I'll ditch my base class rather than risk interfering with bits I don't directly see happening. Cheers guys -- Tim -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/LqppO6Wxoy4J. 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.
