KVStore backend for Django about sorl-thumbnail HOT 5 CLOSED

So, you're trying to implement a cache (based on django cache backend) only?
I never said the django.cache is enough for you to implement a proper key value store enough to cover the needs of the current implementation and infact I don't think its such a great idea to have only non-persistent cache.
Well we need to query the key value store at least once each time for each thumbnail, that should be alot faster than quering the storage backend, thats the whole idea. Do you have some other idea on how this should work? please elaborate in that case so that I could take it in consideration.

from sorl-thumbnail.

The point is that django has a cache system in place.
The thing is, I have the caching setup with memcache, which is used everywhere. So now with the new sorl thumbnail is have the choice between taking tons of database queries or get redis installed on production.

Django cache framework is an abstraction layer which makes it easy to use everywhere and then on time of deployment I can pick the backend I want to use.
It might be redis, it might be memcache and for local development I can use locmem.

You could extend the snippet a bit and specify a thumbnail specific timeout for the cache.set. Thus making the keys lasts longer.

Also, yes, cache is faster then the storage backend, but what if I don't care? Right now you force one way of doing it which is totally different from the previous version.

from sorl-thumbnail.

But the cached db key value store doesn't take a database hit after first query, its loaded into memcached after that (or whatever cache backend you are using). Why don't you want to use this?

i know that the _find_keys_raw method is a bit narrow and I realize that all "key value" stores might not be able to implement this. One approach around the problem would be to keep track of the different 'identities' and keys in special keys, but I rather not, in case this grows to a real problem I will have to figure out a "nicer" way to solve those problems on a more fundamental level. Anyway, as I said I don't think using the django.cache as a key value store is a valid enough use case since I don't think its a good idea.

from sorl-thumbnail.

Ah.. I totally missed it cached because the cache_backend was set to dummy.

My bad :D

from sorl-thumbnail.

Finally if you don't want to use a Key Value Store at all, then just make your own Backend subclass that just looks at the storage or something, that should be an easy job. I am not forcing you to do anything, infact I'd go as far as saying the new design is very modular.

from sorl-thumbnail.