-
Notifications
You must be signed in to change notification settings - Fork 80
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
Support cache tagging #2
Conversation
afaik SonataCacheBundle also does something like this, among many other things. we might inspire ourselves there to see if we can generalize that. |
Also found this. |
Perhaps the most elegant solution is to have one
|
wouldn't the parameters to the cache response and for invalidation be quite different? and for GET its the sensio framework extra bundle that provides the tag, i don't think we can just extend that tag. |
This PR is stil incomplete, as it calls
|
well, ban is all about sending requests with any headers and a special type |
Good point. I made |
@@ -34,13 +38,38 @@ class CacheManager | |||
* @param HttpCacheInterface $cache HTTP cache | |||
* @param RouterInterface $router Symfony router | |||
*/ | |||
public function __construct(HttpCacheInterface $cache, RouterInterface $router) | |||
public function __construct($cache, RouterInterface $router) |
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.
why did you remove the interface?
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.
Because the HTTP proxy classes (Varnish, Nginx, ...) implement (at least one of) BanInterface, PurgeInterface and RefreshInterface, there's nothing left in the HttpCacheInterface. Would you prefer to have the proxies implement an empty HttpCacheInterface instead?
very cool! i commented on a few details. feel free to merge (and maybe squash the commits). btw, i will be in the mountains from tomorrow on for a week, and have no computer with me. |
Thanks for your comments. Enjoy your trip! Being away from computers for some time can be a very good thing. 😉 |
Fix class name Fix typo Clean up test Improve code and add docs Add another expression example Add check for characters in tag name that clash with regex Refactor BanInterface Rename ban to banPath and implement simpler ban method Make cache tags HTTP header settable Add note on dependencies Re-add cache proxy interface Make Varnish tests compatible with refactored BanInterface Make functional test case easier to use Make separate case for when tags are banned Fix banning tags and add functional test Don't flush Varnish if no requests are queued Add flush expectation Explain how to configure Varnish for cache tagging Fix link in docs
*/ | ||
public function __construct(HttpCacheInterface $cache, RouterInterface $router) | ||
public function __construct(CacheProxyInterface $cache, RouterInterface $router) |
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.
ah, now i get it. should BanInterface etc all extend CacheProxyInterface then? it means they are "a kind of cache proxy" which seems to be what we are saying.
Tag your HTTP cache entries, and later invalidate cache entries by tags. This is sometimes called Tagged Cache Invalidation, a simpler version of Linked Cache Invalidation. See also this Drupal proposal.
For Varnish, this will come down to setting a custom header on the response and then banning on that header later.
By the way, Varnish have their own implementation called hashtwo that's probably more efficient, but as it's a paid solution, it's less relevant to us.
See also http://www.gossamer-threads.com/lists/varnish/misc/19732#19732