Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion creating unique numeric IDs in datastore (sample code)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
dundeemt  
View profile  
 More options Apr 27 2008, 9:02 pm
From: dundeemt <dunde...@gmail.com>
Date: Sun, 27 Apr 2008 18:02:15 -0700 (PDT)
Local: Sun, Apr 27 2008 9:02 pm
Subject: Re: creating unique numeric IDs in datastore (sample code)

On Apr 27, 7:15 pm, vrypan <vry...@gmail.com> wrote:

> All mentioning object.key().id() are right. There are some
> implications however:

> 1. Is key().id() really faster than my suggestion?
> It should be. But how much?

> 2. I like Dave Hanson's example. However, what happens if someone
> tries to access the label.id before it stored back?
> Ensuring consistency there may take more resources -or not?

> 3. My "counter" approach has an extra bonus: it's useful when you need
> to know the number of objects stored. Remember, there is no "select
> count()" in datastore, and the key().id() sequence is not well defined
> (the next object you store may have an id that's not last object's id
> +1)

> Jeff, I don't think your synchronization concerns are valid in this
> case. It looks like the implementation I suggested is consistent (the
> counter increments take place in a transaction) and the actual piece
> of information that needs to be replicated between servers is a
> relatively small object. That said, I have no insight on how google
> infrastructure works, so I may be totally wrong. :-)

I too, am hoping someone from Google would weigh in on the issue.
Since, I don't have a GAE account yet, I've had to do most of my
design/testing based on assumptions about synchronization and
replication.  And I could be very wrong. ;)  However, using UUIDs in
places where I would have used auto-incrementing is not that big of a
deal.  It is a surrogate key,  just as an auto-increment field is and
can be created prior to "put"ting the record, so additional db
interactions are not necessary.  So the idea does have certain
advantages.  As to keeping a count of records,  that can be memoized
so the penalty for a COUNT(*) could be amortized out over a large
number of requests.  (I'm not a big fan of surrogate keys but I am a
pragmatist on the topic.)

While the dev environment is apparently quite good in mocking the
python portion and basic table operations, it does leave a lot
unanswered for the implications of replication and synchronization --
I'm not sure if anyone(non-google) completely understands this with
regard to those two topics.  And I don't fault the dev environment,
it's a nice piece of work but it isn't GAE proper<g>, nor could it be
expected to be.

Regards,

Jeff

> I would be nice if Google provided a stress-testing service for our
> apps. Something like ab (Apache benchmarking tool) for AppEngine,
> hosted by google?

> --Panayotis.

> On Apr 28, 1:11 am, Dave  Hanson <d...@drhanson.net> wrote:

> > When I need an id field, I use the unique id for each entity in the
> > datastore. It's a bit of a pain, because must save new objects once
> > before their ids are available, e.g.,

> > class Label(db.Model):
> >   name = db.StringProperty(required=True)
> >   ...
> >   id = db.IntegerProperty()

> > class LabelHandler(webapp.RequestHandler):
> >   def post(self):
> >     ...
> >     label = Label(name=self.request.get('name'))
> >     label.put()
> >     label.id = label.key().id()
> >     label.put()
> >     ...


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.