On Apr 27, 7:15 pm, vrypan <vry...@gmail.com> wrote:
> All mentioning object.key().id() are right. There are someI too, am hoping someone from Google would weigh in on the issue.
> implications however:
> 1. Is key().id() really faster than my suggestion?
> 2. I like Dave Hanson's example. However, what happens if someone
> 3. My "counter" approach has an extra bonus: it's useful when you need
> Jeff, I don't think your synchronization concerns are valid in this
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
> 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?
> 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
> > class Label(db.Model):
> > class LabelHandler(webapp.RequestHandler):
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.