New cache backend
Ivan Illarionov
community. The code is very simple:
http://www.pastethat.com/aNWVB
The main advantage is that it is persistent just like 'db' backend and
in the same time uses memory which you can fine-tune with cache_size
parameter. I believe that this backend is superior to database cache
backend in situations when you need your cache to persist.
It is too simple to start the external project, and cache backends are
not pluggable. So, I would be glad if Django developers integrate it.
(note: don't name the file durus.py -- it will clash with Durus
package, name it like durus_cache.py)
I use something like following in my settings file:
CACHE_BACKEND = 'durus://path/to/my/cache/file?cache_size=200000'
Malcolm Tredinnick
In general, the best way to provide something like this for the
community is to make it available as a third-party application. At the
moment, that isn't entirely simple, since the Django cache mechanism
isn't set up to allow third-party cache procedures. We could make
similar changes to what we did in the database backend to allow
third-party caches to be used without requiring core changes.
I would be against including another caching mechanism in core at this
time, but making the changes to allow third-party caches that provide
the same API as Django's core caches would be a good change to make.
That provides the best of both worlds: room for experimentation with new
systems, without adding extra code to core for something that might not
be used too frequently (and which we would have to maintain forever,
regardless).
Regards,
Malcolm
--
Works better when plugged in.
http://www.pointy-stick.com/blog/
Malcolm Tredinnick
On Wed, 2007-12-26 at 14:01 +1100, Malcolm Tredinnick wrote:
[...]
> In general, the best way to provide something like this for the
> community is to make it available as a third-party application. At the
> moment, that isn't entirely simple, since the Django cache mechanism
> isn't set up to allow third-party cache procedures. We could make
> similar changes to what we did in the database backend to allow
> third-party caches to be used without requiring core changes.
>
> I would be against including another caching mechanism in core at this
> time, but making the changes to allow third-party caches that provide
> the same API as Django's core caches would be a good change to make.
> That provides the best of both worlds: room for experimentation with new
> systems, without adding extra code to core for something that might not
> be used too frequently (and which we would have to maintain forever,
> regardless).
Sorry, that whole post came out horribly. I wrote one version, started
editing and rewriting and then was distracted by a seagull or something
and sent it in a form that only repeated most of what you already said.
I suck. :-(
The second paragraph above is my real point. What I also wanted to add
was that including something like this would be overkill in many
respects. We might as well just fix the existing file backend cache to
handle resource limits if we were going to go down that path. I suspect
it's not high priority since in most cases (1) generating the content
once every now and again doesn't kill you (if it does, your serving
hardware is a bit too feeble), so memcached hits the high-volume sweet
spot and already does more than any hand-rolled version is going to do,
(2) if caching gives you real benefits, it's because you are serving the
same stuff over and over again, so storing one copy of everything you
serve isn't too bad and a periodic cron job to blow away the cache files
is the poor man's working solution if you're using the file-based cache.
Yes, we could build in the second point to the file:/// backend, but it
adds a little overhead to each request (since it's event based, rather
than looping, you obviously have to check when requests occur) and if
you really need that fine-granied control, memcached is probably going
to be a better fit.
Regards,
Malcolm
--
The hardness of butter is directly proportional to the softness of the
bread.
http://www.pointy-stick.com/blog/
Ivan Illarionov
It has all the advantages of both file and database backends coming
with Django plus the memory-based pythonic cache. Of course I could
live without it. But since I wrote it I don't see any reason to not
use it.
The only bad thing about it is that I don't have an easy way to
publish it so more people can use it. Oh, I am going to start a new
thread exactly about this.