eZ Community » Forums » Developer » SmartCacheClear, template-block with...

SmartCacheClear, template-block with subtree_expiry and eZDBFileHandler

SmartCacheClear, template-block with subtree_expiry and eZDBFileHandler

Friday 28 October 2011 4:54:49 pm - 6 replies


I have an issue and some meta-physical questions around cache-blocks and SmartCacheClear.

I have a "menu" content class looking like :

- title <ezstring>
- nodes <ezrelationlist>

I want to use this content class to add link lists to my pages, cached in cache-blocks with subtree_expiry on the menu object's node.

(FYI I use presistent_variable to do this work in pagelayout scope, but this is working fine and is not the issue.)

My problem is that when I publish an item, related via attribute "menu.nodes", I want my "menu" object cache to be cleared.
Having the full view of my "menu" object is easy with SmartCacheClear.
But cache-blocks with subtree_expiry set on my menu object's location(s) won't expire.

It is just not implemented by eZContentCacheManager.

I think this should be implemented as if we expire view cache for a given node, that means all related cache should be expired.

I just hacked eZContentCacheManager, and this may be achieved easily, and the behavior could be "fine-tunable" with viewcache.ini parameters

I think I am going to propose an enhancement on issues.ez.no with a patch but I would like some feed back on the "should the subtree cache-blocks expire when the related content view expire" question.


On the other hand, I noticed that clearing subtree cache-blocks with the API does not work with eZDBFilehandler, as commented in the code :

// We will only delete files if the FS file handler is used,
// if the DB file handler is in use the system will
// instead use the modified_subnode field from the tree structure
// in the database to determine if the cache is expired.
// This reduces the need to perform expensive modifications to the
// database entries for the cluster storage.

This means that eZSubtreeCache::cleanup() just doesn't do anything when in eZDBFileHandler context, because validity is checked against the node modification time and not a specific expiry value for cache-block.

(Query is : SELECT modified_subnode FROM ezcontentobject_tree WHERE node_id=xx)

I think that cache-block validity should be checked against a specific field and not directly against content.

Updating a column in ezdfile at publish time should not be that hard ?



What do you think ?

Saturday 29 October 2011 11:16:44 am

I think any extra flexibility in cache-block management is welcome!

If you search for "cache-block" in the issue tracker, you will find already things like:

1. change the generated names of cache blocks, to allow the developer/admin to expire them one by one (alternative: add a new "id" param in cache block that can be used to the same effect)

2. allow to have a subtree_expiry_depth param used to limit cache-block expiry to some depth - useful eg. for nav menus that list all top-level folders in content tree

3. allow to have an expiry_classes param to limit the classes of content that, when modified, trigger block expiration

I think point 2 and 3 are not possible with the current architecture as you describe it, so trying to change it is a good idea - as long as we are not getting considerably worse performance...

One last note: I am against new ini parameters as much as possible. I'd like new parameters (such as eg "related_object_expiry"blunk.gif Emoticon available in the cache-block tpl function instead

Monday 07 November 2011 12:01:50 pm

Thanks for the feed back.

I think those 3 proposals are additional features, while the expiration behavior of a content is a more low level problematic (although it could be implemented as a feature).

The fact is that if you have a content "A" published and therefore its caches cleared, SmartViewCache rules are used to know what to exactly do.

But if another content "B" publication triggers content A's cache expiration, SmartViewCache rules for content A are not used to know what to do, I think it should (There are of course some recursion matters to handle).

My cache-block issues is the same behavior : cache expiry behavior is different according to the expiry trigger.


Maybe this has already been discussed...


For the "new ini parameters" purpose, what are the pro/cons leading you to this opinion ? 

I have the feeling that "template time" instructions are more difficult to handle, as wa have to collect them in some way... but I admit I did'nt have a big reflexion about that...

Monday 07 November 2011 9:57:02 pm

Well, I think my proposals are for new features, but I think that your one is also a new feature blunk.gif Emoticon

In fact, you could achieve the correct result by having a "link list" item to which the linked items are linked not via an object-realtion(s) attribute, but via multipositioning (ie the linked items get a 2nd location as children of your link-list node). This would have the effect of making your cache-block expire without any hack to the current code.

About the problem you expose in the 2nd post (when view cache of a node is expired because not of it being edited but because of something else), I think that teh default is actually correct: we do not want this recursions to happen as: 1. it would be too easy to trigger clear-all-caches storms, and 2. normally you expire nodes via normal view cache and smart view cache because you display in their full view the info coming from the related objects. In the line-view of nodes, which is used when embedding them in other contents, you usually only display the node name. In short: you want to do a two-hops jump for cache-clearing. I understand your need, but I think it's a bit of a specific need.

About new ini settings: I appreciate fully the flexibility of eZ given by its abundant configurations, but I also come to appreciate systems where maintenance costs are low (and too many ini settings are contrary to that), and where there is a unity of intents, ie. a single place to specify aspects that relate to the same concept.

Smart view cache is imho not a good example of cohesion: it is defined in an ini file, but it is strictly related to both content class definition and content structure (managed via admin interface) and to template code. So to understand if a smart view cache rule is set up correctly, you need to check 3 places at the same time. Even worse, you will have a hard time even understanding if have your smart view cache config complete, as you need to scan 100% of the fetch functions in your templates to find if any of those is actually displaying objects of class X from within the full view template of class Y and hence needs a smartviewcache config line.

Otoh cache block configuration is done within the template, close to the template logic that displays the content of the cache blocks themselves. So you can look at a single file (at least for most simple cases, I admit) and see if there are any problems with it.

Monday 07 November 2011 9:58:15 pm

ps: i also think that eZContentCacheManager should be fully extendable via configurable handlers... THAT would be a pull request I welcome!

Tuesday 08 November 2011 11:10:18 am

I have been faced to that frustating fact that SmartCacheClear rules are not applied in a "cascading" way a couple of time.

Maybe it's my way of building site with eZ wich lead me in such dead ends... but In the classical ez projects constraints, we have : back office-usability VS db weight VS frontend perfs VS cache clearing, and that would be great if the last one could be more customizable to better serve the 3 others.

So I agree, the right solution is definitely to add a "clear cache handler" allowing us to put some project specific logic.

I realized that this may already be partially achieved via custom workflow events without hacking, but available triggers don't match every case (no content/delete, or content/priority for instance).

Tuesday 08 November 2011 10:36:11 pm

I have done "added cache clearing" via workflows, see eg. reverse proxy purge calls from the ezworkflowcollection extension. Itr is not hard to implement, but it has the added problem that you need to fetch all involved nodes / objects again, so perfs are impacted...


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from