Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • David Peck 587 posts 1553 karma points c-trib
    Jul 20, 2018 @ 14:38
    David Peck
    0

    Views on invalidation of CachedPartial by page

    Many will be familiar with:

    @Html.CachedPartial("partialViewName", myViewModel, cachedByPage: true)
    

    cachedByPage works by adding the id of the current page on to key which is used to cache the partial.

    I've had problems with editors not being able to see their changes because the content that they're editing is cached. The workaround I put in place is that I listen for any publish events and clear the entire partial view cache.

    It seems to me that a simple solution would be to replace the use of the page id with the page version, as the page identifier in the cache. Any cached partials for that page would then automatically get re-generated with a new cache key.

    Do you agree? If so I'll send a PR for consideration by HQ.

  • Sotiris Filippidis 249 posts 1221 karma points
    Jul 21, 2018 @ 10:20
    Sotiris Filippidis
    0

    David, I think Umbraco does that for you already. Look at the last line in the documentation here: https://our.umbraco.com/documentation/reference/templating/mvc/partial-views

    Also, the cache of all CachedPartials is emptied on Umbraco publish events.

    I suspect you're having a different kind of problem here. Do your partial views always return the same result for the same node or are they based on some additional data that do not belong to the page being published and may change?

    If it helps, here's a relevant paragraph from the same documentation page:

    However, if your view data is dynamic (meaning it could change per page request) the cached output will still be returned. This same principle applies if the model you are passing in is dynamic. Please be aware of this: if you have a different model or viewData for any page request, the result will be the cached result of the first execution. If this is not desired you can generate your own cache key to differentiate cache instances using the contextualKeyBuilder parameter

Please Sign in or register to post replies

Write your reply to:

Draft