Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache invalidation with partial key knowledge #87

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

WhitWaldo
Copy link

Per the issue I opened just a brief while ago at #86, this pull request is a first pass at an implementation supporting cache invalidation without knowing the entirety of the key.

Since it requires knowledge of the various keys in the cache, I implemented a non-authoritative list of keys that attempt to update along with the various cache operations, but also thus allow for a predicate function to iterate through each of the keys for matches based on partial key knowledge.

This enables a scenario where I have a user identified by a value and want to cache the result of an operation based on the values of any of the parameters to the method. The current LazyCache implementation easily supports the addition of keys to this end, but should I modify any of the data, I may want to invalidate all keys referencing this user even though that identifier is only part of a larger composite.

My pull request enables the user to define a Func that iterates through all the keys that are presumably in the cache to select those to remove, despite lacking the information necessary to produce the whole cached key. I'd appreciate any feedback you have about this.

@agrath
Copy link

agrath commented Sep 4, 2019

+1

I am evaluating this library to replace an internal library that is non-core compatible wrapping HttpRuntime.Cache
In our usage we prefix our keys sort of similar to namespaces so we can invalidate a section of the cache based on what we know. E.G SeriesHelper- and if a series is updated we invalidate based on that prefix (key.StartsWith)
A predicate based approach is much more flexible, though.

I was reviewing the issues and code for the remove method to check for this compatibility and you beat me to it :)

@maranmaran
Copy link

+1

@alastairtree
Copy link
Owner

This is very similar to the newer #153 (and has the same issues)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants