Section edit seems to clear all view caches

[hghandri]

I think we don't have to clear all view cache like this. Moreover expireAllViewCache is a static method.

    static function expireAllViewCache()
    {
        eZExpiryHandler::registerShutdownFunction();
        $handler = eZExpiryHandler::instance();
        $handler->setTimestamp( 'content-view-cache', time() );
        $handler->store();
    }

[Plopix]

+1

[bdunogier]

After looking into it, I don't really see anything this line would actually bring...

So it's a +1 from a technical perspective. From a status perspective, legacy is supposed to be feature frozen, but it's really a small improvement. @andrerom ?

Review ping @dpobel @yannickroger

[ghost]

just a doubt: suppose i create/update a section "archive" that is restricted pointing to a subtree X. if the caches are not refreshed, the objects already in that subtree, accessed by public before, will continue to be public until their caches expire. or the caches affected are refreshed elsewhere?

[bdunogier]

Good point. The thing is that we can't apply a different behaviour for single nodes and subtree roots.

The performances effect of a simple node assignment can be really too much if it is a one node without any children. Clearing cache for the subtrees (all of the content's nodes) would do it, wouldn't it ?

[gggeek]

Not sure if clearing viewcache only for subtree of the modified object is enough. What about a page B listing all products viewable by the public? As soon as I assign product X to the private section, it should disappear from B...

[ghost]

which reminds me also, cache clear for subtrees-> done. objects are now hidden. what about objects outside the subtree that are linked/related? do we trust enough in viewcache settings to trigger cascade caches outside the edited section to remove references to the newly hidden objects?

[ghost]

@gggeek, i think we had the same idea at the same time :)

[bdunogier]

@pbras we have no choice but to trust the smart cache. And if it's not smart enough, fix it. We must just send the clear cache notices, and let the configuration do the rest.

After talking with @Plopix, we agreed on the following:

• clearing all caches because one object's section is changed is overkill
• there is a need for much more than what this PR suggests.

We suggest the following: loop over the modified object's location, and start a subtree search of the object's nodes. If there are less than X objects we should clear cache for, we do. If there is more, we clear all caches.

The threshold could be the same than the viewcache's (smart cache could then decide to clear all caches if the end result, after its computations, end up with more targets than the treshold).

[Plopix]

@gggeek in your example, the viewcache already handles that, isn't it ?

[gggeek]

@Plopix if it does (both viewcache and cache-blocks), then fine