Heyday/silverstripe-cacheinclude - how to create dynamic cache key based off of object id

<%- if @topic_view.topic.tags.present? %>
<%= t 'js.tagging.tags' %>: <%- @topic_view.topic.tags.each do |t| %> <%= t %> <%- end %>
<% end %>

I am looking into using heyday/ silverstripe-cacheinclude on a project and there are two items that I am having issues with

  1. I have a output display of blog posts and on that display I put the number of comments. If I include just the BlogPost in my cache config contains - example -

     Blog:
       context: full
       contains:
         - SilverStripe\Blog\Model\BlogPost
       expires: +1 hour
       member: true
    

If a new comment is added to this post the cache won’t update. If I include the comment class in contains like -

    Blog:
      context: full
      contains:
        - SilverStripe\Blog\Model\BlogPost
        - SilverStripe\Comments\Model\Comment
      expires: +1 hour
      member: true

This works but if anyone comments on any post then all blog caches are invalidated. I also have comments on other sections of the site and other dataobjects so it doesn’t make sense that then any time a user comments on some other section of the site the blog cache would then expire since nothing has changed in that group.

Now I do see that this module handles many_many lists and when those are updated in invalidates as expected but I can’t seem to figure out how to limit with related $has_many or $has_one data.

  1. I have a feed on the site that is user specific and is pretty random so sort of the same issue as above. I want to basically cache each card in that feed so queries like comment count, likes etc don’t need to recalculate again until those change. I see that you can create your own key interface. GitHub - heyday/silverstripe-cacheinclude: Fast Caching for SilverStripe Does anyone know how to create the key where it is referencing that specific object though. With default partial caching from silverstripe you could include things like <% cache ‘BlogPost.$ID’… %> With this module the configurations seem to be more broad whereas it seems it was much easier to target specific objects previously.