Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fixed an issue with settings caching using SettingsRepository
One may have a settings class that includes a mix of HostSettings, PortalSettings, ModuleSettings and TabModuleSettings. The previous mechanism had different cache keys for PortalId or TabModuleId, but that brough 2 problems: 1. It is possible to have the same number for a portalId and TabModuleId which would invalidate the wrong cache. 2. When reading settings using the GetSettings method overload that takes moduleInfo, it would get stale settings for all PortalSettings if it was saved also using moduleInfo overload. I am on the fence about this PR, but it caches now using always portalId. PROS: It fixed the issue at hand. CONS: It clears the portal settings cache to be clear, not the whole portal settings cache but only the specifiec settings class type being requested. This is maybe a tiny tiny bit of a performance hit, but it's not like saving settings is something that gets hammerd. So I believe the benifits here outweigh the drawbacks. Closes #5739 Possibly a different fix for the workaround in #3756 but I don't have any MVC custom module to test that part...
- Loading branch information