-
Notifications
You must be signed in to change notification settings - Fork 2.8k
V13/bugfix/partial cache #19314
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
V13/bugfix/partial cache #19314
Conversation
Added unit tests to verify behaviour.
…d on the key itself.
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.
All looks good to me, tests out as expected and will solve the raised issue.
I just added some header comments to help for anyone looking to understand what these new components are for, and added some unit tests. To support these I refactored out the method of generating the cache key into a method we could expose for testing - that then allowed checking the generated regex correctly matches the cache key.
To verify composition of a custom implementation I re-added the previous behaviour with:
using Umbraco.Cms.Core.Cache;
using Umbraco.Cms.Core.Cache.PartialViewCacheInvalidators;
public class MyMemberPartialViewCacheInvalidator : IMemberPartialViewCacheInvalidator
{
private readonly AppCaches _appCaches;
public MyMemberPartialViewCacheInvalidator(AppCaches appCaches) => _appCaches = appCaches;
public void ClearPartialViewCacheItems(IEnumerable<int> memberIds) => _appCaches.ClearPartialViewCache();
}
And:
using Umbraco.Cms.Core.Cache.PartialViewCacheInvalidators;
using Umbraco.Cms.Core.Composing;
public class TestComposer : IComposer
{
public void Compose(IUmbracoBuilder builder)
{
builder.Services.AddUnique<IMemberPartialViewCacheInvalidator, MyMemberPartialViewCacheInvalidator>();
}
}
# Resolved merge conflic in src/Umbraco.Core/Cache/Refreshers/Implement/MemberCacheRefresher.cs
# Resolved merge conflic in src/Umbraco.Core/Cache/Refreshers/Implement/MemberCacheRefresher.cs
Prerequisites
Fixes #19098
Description
When caching the execution of a partial view by using the
CachedPartialAsync
extension method on theIHtmlHelper
and stating you want it cached by member or not, it seems logical to expect that when a member is updated, only the partials that are cached for that specific member are removed from the cache.Since an IMember gets updated every time it logs in, as the last login date is saved, the partial views cache was fully invalidated every time a user logs in resulting in a very ineffective caching strategy under heavy member load.
In future versions we will look into separating the last login date and similar Identity fields from the domain object to lower the amount of domain object persistence operations we need to do but since this would be to breaking for v13 and because being able to extend/replace only the code that deals with the partial view cache invalidation triggered from a member update is a friendly thing to supply we went with this approach for v13.
We have also made plans to look into similar enhancements for the other CacheRefreshers to split the logic to make it easier to extend in the future.
Notes
I placed the implementation into the same project as the code that builds the cache key. As the core should not hold an implementation that is tightly bound to the workings of a web application. In an ideal scenario the core would define a more abstract interface to run extra cache invalidators but that will be looked at when we investigate the rework of the CacheRefreshers.
Testing
CachedPartialAsync
method or changing the stupTesting code examples
General.cshtml
Member.cshtml
Master.cshtml