IndexedDB caching of settings by Angular (and AngularJS?) should be reconsidered

[Galen Charlton]

While working on bug 1957179, I ran into a situation where it would have been very useful to be able to fetch a user/workstation setting with a guarantee that it was coming from the Evergreen database rather than an IndexedDB cache.

Consider the following scenario:

- user regularly edits item records from two different computers
- user creates and saves holdings templates on computer A, saved as a user setting (once bug 1957179 is fixed)
- user goes to computer B, where they're logged into Evergreen, and goes to edit some items. However, they look at the list of holdings templates and don't see the new ones they added. They hit refresh, repeatedly, to no avail. They grumble, recreate one of the templates and save it.
- the next date, the user goes back to computer A, which had rebooted. They log into again, and see the template they added on computer B, but the ones they originally added on computer A are lost.

This can easily come across to the user as "Evergreen is incapable of consistently saving and retrieving settings and will lose work that I put into them". That may be a bit harsh of a statement, but then, we all know that cache invalidation is one of the two hard problems in computer science.

Now, per the discussion in bug 1848550 when IndexedDB caching was added, the user can just log out and back in to clear the IndexedDB cache of settings.

However, in retrospect I think that that isn't particularly friendly for settings that are liable to be changed by frequent user action, including holdings templates. A common pattern in other web apps would be more along the lines of "refresh the page if you're not seeing a change you're expecting", and as compared to logging out and back in, simply doing a refresh is rather less likely to lose the user's place in their workflow.

I must admit that I'm tempted to suggest that settings simply don't get cached in IndexedDB at all in favor of per-tab local caching via the settings storage services in Angular/AngularJS and evaluate whether the additional settings retrieval calls that would arise would actually be a significant problem.

That's a bit extreme; alternative suggestions include:

- adding methods to the Angular/AngularJS server-side settings services to fetch settings while bypassing the IndexedDB cache
- adding metadata (maintained in the source code? a column in the settings types tables?) to indicate that particular settings should not be cached
- if page refreshes (as opposed to normal navigation) can be detected reliably, consider clearing the IndexedDB settings cache upon refresh
- teach the IndexedDB cache the notion of timeouts (and keep them relatively short)
- add top-level menu action to clear the settings cache (though this seems hacky)

[Galen Charlton (gmc)]

See also bug 1938729

[Bill Erickson (berick)]

I like the direct control offered by a "no cache" column on the setting type.

I also like the idea of default, relatively short timeouts.

I'm not opposed to a hacky "kill the setting cache with fire". I could see it in a less prominent place, too, maybe in the Workstation admin area, so it does't become a so easily a crutch.

Combine all 3?

I recall when caching was first proposed in the AngJS side, it was addressing a real problem. I would be wary of tab-local caching, but open to experimentation.

--

The code for bug #1904036 has code to support loading/caching the offline data, including IndexedDB cache timeout support. There's likely some crossover here.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob;f=Open-ILS/src/eg2/src/app/staff/share/offline.service.ts;h=4130d24fe8b9f1ccf91a2a2d632ca47af83ad12d