Comments on: Caching Layer for Django ORM

By: Andy

Andy — Wed, 04 Mar 2009 17:43:31 +0000

Bump for emmby’s question. I’d like to use this but don’t want to get it to production only to be bitten by some subtle immaturities. Is it pretty well baked?

By: emmby

emmby — Sun, 01 Feb 2009 00:23:20 +0000

I’d also love to hear about the status of this project. It’s the first hit on google when you do a “django orm cache” search, but it looks like it’s been inactive for a little bit of time. Are people using this? Does it seem reliable?

By: Roman

Roman — Sun, 14 Dec 2008 23:01:16 +0000

Hey David, thanks for this great caching layer. I was just wondering, were you planning on formally making a release soon? It seems like the last code changes were made back in February (from http://code.google.com/p/django-orm-cache) and I’d love to start using this in some of my projects, but it’s difficult to track without versioned releases.

By: John

John — Thu, 28 Feb 2008 21:18:30 +0000

I had some difficulty getting this to work out of the box with the OneToOneRelation (I know it’s not exactly in wide use, but until I have model-inheritance, it’s the best fit for several aspects of my data model), and with Generic Relations.

After a couple tweaks to the code to get it to run (which could very well have broken it), I was finding on average the number of queries required to generate my pages went down by 1-3, and the effect was negligible. For this test, I simply changed all of my models to inherit from CachedModel instead of models.Model.

By: David

David — Thu, 24 Jan 2008 00:49:24 +0000

We did tests showing a 2x-5x increase in time for a standard cache call of 10-50 objects. It will be a little bit higher of course with the overhead of iterating through loops, but all in all it’s going to provide a means of invalidation and still be far more efficient than SQL.

By: Al

Al — Tue, 22 Jan 2008 11:46:11 +0000

David,

While I expect you haven’t done any in depth performance testing – have you given it any sort of a work out to give some sort of an indication of the possible benefits this is going to yield for you?

Al.

By: David

David — Tue, 22 Jan 2008 06:24:43 +0000

One quick note is that I haven’t actually put much thought into optimizing counts. And it currently doesn’t invalidate them.

By: Jan Oberst

Jan Oberst — Tue, 22 Jan 2008 05:47:42 +0000

I like this a lot! When I started developing my django app most pages made like 50 seperate foreign key requests each for a single ID to the database. I even had queries for the same ID.

Because I really have to focus on DB speed I can’t use Django’s select_related function. That’s why I’m now caching foreign key lookups with memcache get_many calls (Just hacked this code direclty editing Django sources for now).

I had most problems with foreign key lookups and obviously count() queries – and it’s amazing to have Django’s ORM to manage all that caching transparently behind the scenes. Great job!