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

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.

Reply via email to