Added the concept of image cache backends. Image cache backends assume
control of validating and invalidating the cached images from ImageSpec in
versions past. The default backend maintins the current behavior: invalidating
an image deletes it, while validating checks whether the file exists and
creates the file if it doesn’t. One can create custom image cache backends to
control how their images are cached (e.g., Celery, etc.).
ImageKit ships with three built-in backends:
- imagekit.imagecache.PessimisticImageCacheBackend - A very safe image
cache backend. Guarantees that files will always be available, but at the
cost of hitting the storage backend.
- imagekit.imagecache.NonValidatingImageCacheBackend - A backend that is
super optimistic about the existence of spec files. It will hit your file
storage much less frequently than the pessimistic backend, but it is
technically possible for a cache file to be missing after validation.
- imagekit.imagecache.celery.CeleryImageCacheBackend - A pessimistic cache
state backend that uses celery to generate its spec images. Like
PessimisticCacheStateBackend, this one checks to see if the file
exists on validation, so the storage is hit fairly frequently, but an
image is guaranteed to exist. However, while validation guarantees the
existence of an image, it does not necessarily guarantee that you will
get the correct image, as the spec may be pending regeneration. In other
words, while there are generate tasks in the queue, it is possible to
get a stale spec image. The tradeoff is that calling invalidate()
won’t block to interact with file storage.