First of all, if you really care about the performance, store those
data in static directly and let the app engine directly return it (and
update the whole app when you need to update the data).
Second, please be aware that caching object may not be the most
efficient way. In many cases, caching the final output (typically HTML
file or JSON file) in memcache gives you the best performance. I am
using this technique in all my projects, and it is working very
well.
If you still want to cache objects, here is my suggestion.
While creating a fancy generic class that automatically performs
caching seems clever and elegant, that kind of architecture tends to
create more headache in future when the project gets bigger and more
engineers are involved. I much prefer to hook get/put accesses
explicitly for each class.
Here is a piece of code I am using in my project (cacheman is my
memcache name space manager where I can easily control the namespace -
which is a good practice).
SEC_USER = 60*60 # one hour
@classmethod
def get_user(cls, uid):
cache_key = cacheman.user(uid) # which performs ("/user/
%s" %s uid)
user = memcache.get(cache_key)
if user:
return user
user = cls.get_by_key_name(uid)
if user:
memcache.set(cache_key, user, SEC_USER)
return user
def put(self):
cache_key = cacheman.user(self.key().name())
memcache.set(cache_key, self, SEC_USER)
return super(User, self).put()
Please notice that I am overriding put() method so that I always call
memcache.set, but NOT overriding get_key_by_name (this is just my
preferred coding style, which you don't need to follow).
Please be aware that you need to just get keys when you perform query,
and use the accessor (in my case get_user) to get the actual object.
Satoshi
On Feb 1, 3:40 am, k3xji <[email protected]> wrote:
> Hi all,
>
> I am thinking of away to imlement a generic way for my frequently
> readed data models. The access pattern for these models is that they
> will be retrieved very frequently but updated maybe once in a month.
> Think aboiut a game site. Game categories will not and should not be
> updated at the time they are created. BUt these will be used in my
> front page so every page request will query the db for all the game
> categories. So best way is to memcache these entries.
>
> So, what you prefere as a best practice for these kind of things? I am
> thinking of a generic class that takes a model as a parameter and
> hooks the put() method of it. If model is somehow changed, I will
> update a dirty flag and retrive the contents from the DS, otherwise
> get it from the memcache. But not sure, how to hook all db
> operationsof a model, there are many ways to do that and I am assuming
> there must be a better way to do this, maybe someone else has already
> done this work? Is there a generic way to do this?
>
> Thanks,
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
