Jeff, I agree with the majority of your design philosophy and the advice you're dispensing, but I still disagree with you on one pretty fundamental point. If I'm understanding your argument correctly, you're saying that best practices for primary key management don't involve user-defined strings, therefore user-defined strings aren't a necessary feature, but I think this ignores a pretty basic usage of uniqueness constraints. Let's say you're a domain registrar, you're building your registration workflow on App Engine, and you need to guarantee that a domain name can only be claimed once. If you use a numeric id mapped to the domain name you run the risk of letting two users reserve the same domain, and if you're a domain registrar that's really really bad. There's no natural key we can bring in here. Whether we as application developers run into them frequently or not, there exists a class of problems where a user-defined string pk is a necessary part of the solution.
Regards, Max On Mon, Feb 22, 2010 at 1:52 PM, Jeff Schnitzer <[email protected]> wrote: > On Mon, Feb 22, 2010 at 1:19 PM, Max Ross (Google) > <[email protected] <maxr%[email protected]>> wrote: > > > > user-defined long-id keys are not quite as easily used. You either need > to > > commit to not letting the datastore generate ids for that kind or you > need > > to reserve a batch of ids using the DatastoreService.allocateIds method. > > Otherwise you run the risk of a silent collision. There is no such risk > > with user-defined string keys. > > Right, but if the user has a natural key (long, String, whatever) they > won't be using the generator anyways. There are plenty of natural > long keys in the world... facebook userid being a popular one. > > FWIW, Objectify makes the distinction between ids of type Long, which > can be null and thus autogenerated, and long (the primitive) which > cannot be autogenerated. I really hadn't intended to plug Objectify > here, really! > > > Valid point about renaming, but going back to the example I provided, the > > datastore does not distinguish between inserts and updates. The only way > > you can guarantee that an entity was inserted, and therefore the only way > > you can guarantee the uniqueness of the name, is to use a user-defined > key. > > If you're mapping id to name it will be possible to create two entities > with > > the same name. It's of course up to you to decide how important this is > to > > defend against, but without the ability to provide your own id you > wouldn't > > get to make this choice, and without the ability to provide your own > string > > id you wouldn't be able to add some application-specific meaning to this > > choice. > > I totally agree with you WRT user-defined vs generated values, I just > don't see anything wrong with using the long id as a user-defined > value. Just make sure you never ask for a generated one. Seems > pretty straightforward. > > Jeff > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine for Java" group. > To post to this group, send email to > [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-appengine-java%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" 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-java?hl=en.
