CODEWITHSUNDEEP
pythongoogle-app-engine
boatcoder
boatcoder

Reputation: 18117

What is the most efficient way to do a ONE:ONE relation on google app engine datastore

Even with all I do know about the AppEngine datastore, I don't know the answer to this. I'm trying to avoid having to write and run all the code it would take to figure it out, hoping someone already knows the answer.

I have code like:

class AddlInfo(db.Model)
     user = db.ReferenceProperty(User)
     otherstuff = db.ListProperty(db.Key, indexed=False)

And create the record with:

info = AddlInfo(user=user)
info.put()

To get this object I can do something like:

# This seems excessively wordy (even though that doesn't directly translate into slower)
info = AddlInfo.all().filter('user =', user).fetch(1)

or I could do something like:

class AddlInfo(db.Model)
     # str(user.key()) is the key to this record
     otherstuff = db.ListProperty(db.Key, indexed=False)

Creation looks like:

info = AddlInfo(key_name=str(user.key()))
info.put()

And then get the info with:

info = AddlInfo.get(str(user.key()))

I don't need the reference_property in the AddlInfo, (I got there using the user object in the first place). Which is faster/less resource intensive?

==================

Part of why I was doing it this way is that otherstuff could be a list of 100+ keys and I only need them sometimes (probably less than 50% of the time) I was trying to make it more efficient by not having to load those 100+ keys on every request.....

Upvotes: 3

Views: 80

Answers (2)

Nick Johnson
Nick Johnson

Reputation: 101149

The second approach is the better one, with one modification: There's no need to use the whole key of the user as the key name of this entity - just use the same key name as the User record.

Upvotes: 0

Drew Sears
Drew Sears

Reputation: 12838

Between those 2 options, the second is marginally cheaper, because you're determining the key by inference rather than looking it up in a remote index.

As Wooble said, it's cheaper still to just keep everything on one entity. Consider an Expando if you just need a way to store a bunch of optional, ad-hoc properties.

Upvotes: 1

Related Questions