You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The destructor of the SQL context deletes all files from the cache.
Would it make sense to have an option to keep the local cache alive?
The fetch_asset function would then have to check the local cache.
It could be a bit tricky to compare the date modified between local files and the database version though.
An alternative is to serialize the cache on teardown and attempt to load it on init.
The text was updated successfully, but these errors were encountered:
I would rather make it an option via environment variables. That makes switching between behaviors way easier, and no need to distribute two different binaries.
Other than this, to make this happen we need to name the local files so they are easier to look up, and make the local cache directory configurable.
If you serialize the cache on teardown and try to load it on init, you wouldn't need to make the filenames easier. On the other hand... I'm not using generate_name but a configurable cache dir with simple filenames, unfortunately this prevents the use of multiple versions of the same asset in a single stage (as it gets stored to the same location).
The destructor of the SQL context deletes all files from the cache.
Would it make sense to have an option to keep the local cache alive?
The fetch_asset function would then have to check the local cache.
It could be a bit tricky to compare the date modified between local files and the database version though.
An alternative is to serialize the cache on teardown and attempt to load it on init.
The text was updated successfully, but these errors were encountered: