Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Rework cache key handling in caching client / generator #5641
Rework cache key handling in caching client / generator #5641
Changes from 1 commit
9636018
fd5e3b9
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stephentoub Just a thought - should this function also be overridable? If a derived class were to take over the cache key computation by overriding
GetCacheKey(bool, IList...)
above, would it be surprising that callingbase.GetCacheKey(ReadOnlySpan<object?>)
in further derived classes does something different / uses a completely different hashing algorithm than calling `base.GetCacheKey(bool, IList...)?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I follow. base.GetCacheKey(bool, IList, ...) uses base.GetCacheKey(ROS). The intent is the latter represents the default algorithm for handling multiple objects. An override of GetCacheKey(bool, IList, ...) can delegate to either of the methods on the base.
Could you elaborate on the concern? I'm not clear on what making it virtual would solve. Maybe it needs a different name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah here is an example of what I meant. Consider the case where we have
EvaluationCachingChatClient
that is derived fromDistributedCachingChatClient
and that ships as part of a hypotheticalEvaluation
library 😄EvaluationCachingChatClient
takes over the cache key computation by overridingGetCacheKey
and uses a its own custom hashing algorithm for this.Now consider the case where a consumer of this
Evaluation
library wants to inheritEvaluationCachingChatClient
and tweak the hash computation to include a few additional custom parameters without changing the hashing algorithm used inEvaluationCachingChatClient
. If this derived implementation were to call thebase.GetCacheKey(ReadOnlySpan<object?>)
for this, the key that is returned could look very different from the key returned frombase.GetCacheKey(bool, IList...)
.Depending on how different the caching algorithm used in the two base types happens to be, the returned key could have different lengths, different set of allowed characters (which could be important if the key is used as the name of a file or directory on disk for example) etc. This could be especially problematic in cases like below where the derived class wants to keep the base implementation unchanged in the default case and override only it under certain conditions.
Each level in the inheritance hierarchy has a choice between the following options -
And regardless of which choice is made in a particular inheritance level, it would be ideal if subsequent derived implementations can also retain the same flexibility to
Having the ability to individually override
GetCacheKey(bool, IList)
andGetCacheKey(ReadOnlySpan<object?>)
could be one way to accomplish the above. Yes, I agree we should probably give different names to the two functions for clarity in this case.Another option may be to eliminate
GetCacheKey(ReadOnlySpan<object?>)
fromDistributedCachingChatClient
and make it available as a standalone static helper. However, in this case, every level in the inheritance hierarchy that wants to use some custom hashing algorithm would need to make similar static helpers available for their own derived types...I realize my response is a bit rambling and perhaps I am over thinking it 😄, but I hope this clarifies the concern. Happy to sync up offline to discuss if needed.