On Mon, 2010-02-22 at 15:13 -0800, Jeff Schnitzer wrote: > It sounds like you were trying to generate long ids from an in-memory > singleton, which is a perilous thing to do... there is never a > guarantee that there is only a single instance of your application > running on a single machine in appengine. > > In general... if you have a natural key, use it, otherwise use the > generator. Most data modelers say you shouldn't even use natural keys > (like email), since what you think is a natural key today turns out to > be a mutable field tomorrow (ie, new requirement: users can change > email addresses). I'm pretty partial to that philosophy myself, and > rarely use natural keys - facebook userid being my main exception. > > Jeff
Yes, i am aware of this. Google uses it and calls the unique name within the system the canonical name whether the name is an email or just a convenient id like the Wave id. I copy google idea. Any comment? Thanks BaTien > > On Mon, Feb 22, 2010 at 2:46 PM, Duong BaTien <[email protected]> wrote: > > Hi Jeff and Max: > > > > Sorry to jump in this debate on the use of system generated Long id and > > user-provided long id and String name. I found the discussion is useful > > from best practice. > > > > I leverage Objectify and try to re-do our data model. Originally, i > > chose the route of String name for user, role and group to enforce the > > unique name of the entity Key, plus long id provided from a simple > > ConcurrentHashMap Singleton. But i feel that the home-grown > > ConcurrentHashMap Singleton may not be as robust and scalable as the > > generated Long id, recognizing that the generated id is not contiguous. > > So i decided the use of String name of natural uniqueness such as email > > for user lock-in and generated Long id is for others. > > > > Please comment and/or siggestion. > > > > Duong BaTien > > DBGROUPS and BudhNet > > > > On Mon, 2010-02-22 at 13:52 -0800, Jeff Schnitzer wrote: > >> On Mon, Feb 22, 2010 at 1:19 PM, Max Ross (Google) > >> <[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]. > > 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. > -- 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.
