galaxy icon indicating copy to clipboard operation
galaxy copied to clipboard

Purging tag cache

Open astrovsky01 opened this issue 1 year ago • 3 comments

After using tags for a while, the suggested window for tags becomes a bit cumbersome. One-off tags for a specific analysis are suggested for long after they're useful. Is there a way/could there be a way to purge this cache and reset to empty?

Screenshot 2024-02-08 at 9 36 13 AM

astrovsky01 avatar Feb 08 '24 18:02 astrovsky01

An option here might be to constrain suggested tags to the active history. We could make this configurable by the user as well, but it seems like the history constraint would provide your most useful options without much work.

dannon avatar Feb 08 '24 18:02 dannon

Another approach may be to re-order these to have the most recent ones on top, instead of being sorted alphabetically

ElectronicBlueberry avatar Feb 12 '24 09:02 ElectronicBlueberry

Proposed solution is to shift suggested tag handling to the client completely, which has several benefits.

Grabbing the most recently used tags, or a set of otherwise most useful tags is not currently particularly accessible in the data model and would require back-end additions, but relying on tags the client adds and sees does all the work for us. The tag component can simply register tags in a session-storage persisted pinia store on creation or display, building the list of likely tags to use through actual use and navigation in Galaxy. We could additionally persist this to prefs somewhere if there is a significant concern about losing this between machines or with cache clears, though I think it would naturally refill the local cache pretty quickly to the things the user cares about just on page/history load when those tags are seen, or at least well enough for a first pass.

It's worth noting the way the current user_tags works we currently fill this on every page serve as well, dumped into the initial user payload. Instead of doubling down on querying the appropriate tags on the server and potentially making the tag query even more expensive, by shifting to the client we'll be able to completely drop that expensive get_user_tags functionality from a ton of requests (expensive to query and also potentially quite large to serve, for users with many many tags).

dannon avatar Feb 14 '24 03:02 dannon