-
Notifications
You must be signed in to change notification settings - Fork 169
add cache entry metadata to event args #539
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
base: main
Are you sure you want to change the base?
Conversation
|
Hi @BenRib , thanks for the PR. |
|
Hi @BenRib , the I marked it as I'm currently thinking of revamping the events system for FusionCache v3, along with some other big things: having said that, I don't have an ETA yet and will take some time. Do you have a strict, concrete need for something like this now? Or it was more of a nice addition? Thanks, let me know. |
|
Hi @jodydonetti, Thanks for taking the time to review the PR. I have a case similar to what is described in #453. The other approach I thought of to make these details available to the consumers was using |
I've updated the events to include the cache entry metadata when possible.
The purpose is to let event subscribers have access to the metadata to take further actions based on attributes such as
LastModifiedTimestamporEagerExpirationTimestamp.To avoid breaking changes on the public API, I've kept the event delegates as they are and added new constructors to the event args classes where metadata were added.
New classes have been created when the events relied on the base event args. However, these are not part of the delegates as that would have resulted in breaking changes. It is still possible for the consumers to cast the received args to access the metadata property.