SBarnes wrote:Would it be worthwhile having some sort of api call to support this, that way a plugin could make the call either on a schedule basis to help maintain the cache, or something could be added to the user interface say in system settings to let the user make this happen, I did a similar thing in system settings to restart the api and reread the system setting in the extension for our friends who went live in February.
I am planning to have APIs to manage cache entries, and as a stretch goal have a user interface in the Jiwa application to consume these APIs to manage the cache entries (show a filterable list, with the option to delete an entry).
Having said that, the session cache keys do have an expiry so they'll automatically be evicted from the cache when they do expire, and we clean up the Jiwa side of things (orphaned Manager instances in the JiwaSessionDictionary) by looking for all JiwaSessionDictionary entries which don't appear in the caches session cache entries - we do that each time a request is made.
Previously I was lamenting the fact that DTO's cached as a result of requests made using a Debtor API Key would have to have their key salted with the Debtor API Key, lest we return a DTO previously cached as a result of a non-Debtor API Key request. As it turns out, despite actually implementing that and getting it working just fine, I found it was all for nought as even if the DTO cached is the full DTO, when a request is made using a Debtor API Key to retrieve the DTO, the response filters we already have in place will sanitise the DTO and remove the naughty bits anyway.
So - time was wasted putting all that logic in worrying about unwanted information disclosure, and time was then wasted undoing all that - but at least it's back to being a cleaner solution.
I've done the cache invalidation / refresh / delete when users of the Jiwa application make changes to a record - it piggybacks off what we did with webhooks - so we have business logic handlers for the SaveEnd of all relevant business logic objects and that will call an internal route of the API to update or delete (if they were deleting a record) any cached entries... meaning if caching is enabled, using the Jiwa application will keep the cache up-to-date. We only update cache entries when changes are made from the Jiwa application IF and ONLY IF there was already a cache entry. Cache entries are only added when consumers of the API make requests which results in a DTO being stored in the cache. This strategy is to keep the cache from eventually just being a cache of the entire Jiwa database - we only cache what we need.
I'm about to start on tackling AutoQuery caching - that should be quite a challenge.