Problem/Motivation

FileEntity::getCacheTags returns an empty array. This breaks the cache invalidation for File entities in Views for example.

IRC log

<webflo> berdir: http://cgit.drupalcode.org/file_entity/tree/src/Entity/FileEntity.php#n500 i think FileEntity:: getCacheTags returns no cache tag. i think this breaks tag-based cache invalidation in views. 

<webflo> i use field based rendering in views, no rendered entity 

<berdir> webflo: hm, yes, that is possible...

<berdir> webflo: tricky. that optimization is quite important for us/anyone who has lots and lots of files on overview pages. maybe we could make it configurable? but then you still have to know that you have to change that settings

<berdir> webflo: maybe we can somehow apply the logic from \Drupal\file_entity\Entity\FileEntityViewBuilder to it?

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webflo created an issue. See original summary.

webflo’s picture

Issue summary: View changes
webflo’s picture

Issue summary: View changes
webflo’s picture

Issue summary: View changes
webflo’s picture

Issue summary: View changes
webflo’s picture

Issue summary: View changes
webflo’s picture

This change has was introduced in fbf9a5a. I don't understands whats the reason behind the change. Is it related to cache invalidation for embedded files (in text fields)? Lets see hat happens if we remove that optimization. It should pass from what i understand.

webflo’s picture

Berdir’s picture

Hm, didn't we discuss why this was done at some point? Or was that with someone else?

Basically, the causes an explosion of cache tags if you have a lot of files on your nodes, this saves us dozens of cache tags on frontpages that almost never change.

Can explain the views use case a bit more? I can see how that could be a problem in some scenarios, but maybe we can find a better solution for that, basically the same as the fix in the view builder basically?

webflo’s picture

joseph.olstad’s picture

Status: Active » Needs review
Berdir’s picture

Status: Needs review » Closed (works as designed)

This was actually set to active on purpose, discussed that with @webflo as he's just rerolling this for this project that needs this for nw.

But I'm closing it now as works as designed unless someone can convince me otherwise :)

joseph.olstad’s picture

Ok, thanks for the explanation.

zviryatko’s picture

@berdir it also breaks the JSON API module, since individual resource (File entity) still accessible without cache tags and once you update file data cache not updated automatically.

webflo’s picture

Another update.

@zviryatko Whats your workaround for JSON API module? Maybe we can find a common solution ...

webflo’s picture

FileSize
4.78 KB
Berdir’s picture

Status: Closed (works as designed) » Needs work

Lets reopen for now. Maybe we can make it a setting, document that the current mode is better for performance as it avoids possibly a ton of extra cache tags but some use cases like decoupled might not work?

zviryatko’s picture

@webflo, I've used this patch for fixing jsonapi cache issues, but file_entity requires few other changes to work with jsonapi and jsonapi_extras.

vflirt’s picture

I have stumbuled on this issue as we have some code that does not properly populate the file_usage table which results in cache not being cleared. I am updating the patch for latest dev.