-
-
Notifications
You must be signed in to change notification settings - Fork 498
Description
Description
The v13.0.0 release changed ImageFile.serialize_storage() to return storage aliases (e.g., "default") instead of backend class paths (e.g., "django.core.files.storage.filesystem.FileSystemStorage"). While this fixes issues with cloud storage backends preserving OPTIONS, it introduces a breaking change that was not documented: all existing cached thumbnails may become orphaned after upgrading.
Explanation
The ImageFile.key property computes a unique key based on the image name and serialized storage:
@property
def key(self):
return tokey(self.name, self.serialize_storage())In v12.x, serialize_storage() returned the backend class path. In v13.0.0, it returns the storage alias when one is found:
def serialize_storage(self):
# ...
backend = f"{cls.__module__}.{cls.__name__}"
# Try our best to find and serialize the storage alias instead of the backend class.
for alias, params in storages.backends.items():
if params.get("BACKEND") == backend:
return alias
return backendSo this means:
- v12:
serialize_storage()->"django.core.files.storage.filesystem.FileSystemStorage"(or similar) - v13:
serialize_storage()->"default"
Ultimately, different storage serialization -> different key -> cache miss -> regenerate thumbnail. The old thumbnails are left orphaned, i.e., they still have an entry in the cache/database and their file remains in storage.
Impact
- All existing thumbnails in the KVStore become unreachable (lookups use new key format, pre-existing cached entries use old format)
- All thumbnails regenerated on first request after deploy
- Old thumbnail files left orphaned in database/cache/storage
Reproduction
Minimal reproducible example: https://github.com/SupImDos/sorl-thumbnail-cache-key-mre