If you have an account that looks like this:
class Account {
@Id Long id;
String email;
}
Two people can create Accounts at the same time with the same email
address. Or someone could change their email address at the same time
someone creates an account. Or two people could change
Ah yes good point re the separate entity groups not allowing a query.
On 23 Feb 2010, at 15:50, Jeff Schnitzer wrote:
If you have an account that looks like this:
class Account {
@Id Long id;
String email;
}
Two people can create Accounts at the same time with the same email
address.
I hate to be the dork that argues with the referees, but I'm not fond
of this advice...
* long-id keys can be user-defined just as easily as string-name
keys, so you can enforce uniqueness constraints either way if you have
some sort of natural key.
* Readable urls are a high level construct,
On Mon, Feb 22, 2010 at 12:54 PM, Jeff Schnitzer j...@infohazard.orgwrote:
I hate to be the dork that argues with the referees, but I'm not fond
of this advice...
No problem, I'm happy to discuss.
* long-id keys can be user-defined just as easily as string-name
keys, so you can enforce
On Mon, Feb 22, 2010 at 1:19 PM, Max Ross (Google)
maxr+appeng...@google.com 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
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
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,
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
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,
I don't think we're disagreeing - user-defined keys are the only way
to enforce uniqueness. I was just trying to point out that
user-defined longs work just as well for enforcing uniqueness as
user-defined Strings if your natural key is numeric. There's no
reason to convert it to a String.
I
I don't see what extra protection storing an email as a separate
entity buys you. If you store the same email address twice you do not
get an exception thrown like in an RDBMS... it just silently
overwrites the existing one. In either case, storing the email as a
key or as a field, you
Hi,
What is the intended purpose of keyName when creating a new Key or new
Entity in the low-level API? What are the proper use cases for
keyName?
Thanks!
Chris
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To post to this
12 matches
Mail list logo
