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!
David Cramer
· 1 year ago
One quick note is that I haven't actually put much thought into optimizing counts. And it currently doesn't invalidate them.
Al
· 1 year ago
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.
David Cramer
· 1 year ago
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.
John
· 1 year ago
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.
All Comments
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!
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.
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.