The process of looking up Sunset image assets adds a lot of complexity and slowness, especially for pages with a lot of different images (like a thumbnail grid), and the category/tag thumbnail relationship remapping planned in #107 and #111. So, caching this could help. However, it could also cause more problems than it solves: If the image asset URLs are cached, there's no need to include those in the database queries as select_related/prefetch_related parameters - in fact, it's pointless to cache them if we're still running these queries. But caching systems are inherently supposed to be ephemeral, so for any image asset that isn't already cached, there would have to be a fallback method that queries the database to get the URL, which is an even slower process.
There are two possible solutions to this:
Add a background process to rebuild the asset URL cache whenever the cache is manually cleared, effectively treating the cache like a secondary database (aka the way everyone tends to use Redis like a relational database than a proper cache engine)
Add a field (perhaps a JSONField) that stores this in the normal database as part of the image model, or even a sidecar model, to make it a little more resilient
As of this writing, I'm not sure which of these options would be a net positive overall; I was leaning toward option 1 until I started writing, and then changed my mind mid-ticket, so now I'm leaning toward option 2.
The process of looking up Sunset image assets adds a lot of complexity and slowness, especially for pages with a lot of different images (like a thumbnail grid), and the category/tag thumbnail relationship remapping planned in #107 and #111. So, caching this could help. However, it could also cause more problems than it solves: If the image asset URLs are cached, there's no need to include those in the database queries as select_related/prefetch_related parameters - in fact, it's pointless to cache them if we're still running these queries. But caching systems are inherently supposed to be ephemeral, so for any image asset that isn't already cached, there would have to be a fallback method that queries the database to get the URL, which is an even slower process.
There are two possible solutions to this:
As of this writing, I'm not sure which of these options would be a net positive overall; I was leaning toward option 1 until I started writing, and then changed my mind mid-ticket, so now I'm leaning toward option 2.