Skip to content

Conversation

@BenRib
Copy link

@BenRib BenRib commented Sep 22, 2025

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 LastModifiedTimestamp or EagerExpirationTimestamp.
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.

@jodydonetti
Copy link
Collaborator

Hi @BenRib , thanks for the PR.
I'm currently off for my "summer" vacations with limited connectivity, and I'll be back next week: I'll take a look then.

@jodydonetti
Copy link
Collaborator

Hi @BenRib , the FusionCacheEntryMetadata is meant to not be used directly, as it contains low level internal informations that can change over time.

I marked it as public because that is physically needed by the serializers adapters, but apart from that it's not meant to be publicly used (in fact is in the Internals sub-namespace).

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.

@BenRib
Copy link
Author

BenRib commented Oct 20, 2025

Hi @jodydonetti,

Thanks for taking the time to review the PR.

I have a case similar to what is described in #453.
I was able to implement what I needed with FusionCache using TryGet and Set rather than GetOrSet because the factory retrieves a collection of entries at once while I want each item of the collection to be a separate cache entry. The one feature that I'm missing with this approach is eager refresh.
Unfortunately, the eager expiration timestamp is not accessible other than with the FusionCacheEntryMetadata. By adding the metadata in the event, the eager expiration timestamp becomes available and a manual eager refresh can be implemented by subscribing to the event Hit.
Because the FusionCacheEntryMetadata contains other valuable pieces of information such as ETag and LastModifiedTimestamp, I thought of adding it to the events rather than only adding the EagerExpirationTimestamp.

The other approach I thought of to make these details available to the consumers was using MaybeValue<> but that felt more disruptive for the library than enhancing the event.

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.

2 participants