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 gr
1) Readable-urls. http://yourapp.appspot.com/users/max versus
http://yourapp.appspot.com/users/192398411324987
2) The datastore doesn't support uniqueness constraints so a user-defined
key is the only way you can do a true createIfNonExistent() method:
beginTxn();
Entity e;
try {
e = lookupByK
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, a
On Mon, Feb 22, 2010 at 12:54 PM, Jeff Schnitzer wrote:
> 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 uniqueness const
On Mon, Feb 22, 2010 at 1:19 PM, Max Ross (Google)
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.
> Otherw
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 an
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, otherwi
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 app
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 don
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 wo
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 thei
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. O
13 matches
Mail list logo