Problem/Motivation
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Higher level storage mechanisms like entities and references between them automatically provide cacheability metadata, which is already useful, but AFAICS they do not provide a way for more general queries building non-persisted relationships with cardinality 0-n, meaning they have no automated way to add the existence of that relationship to users of their results. Consider this example, in a headless scenario to put the renderer context out of the way:
* an API response provides a result made of an entity a of type et_a and id id_a, and other entities b* of type et_b related the contents of "a" without any entity_reference relationship between them. Assuming use of actual entities and not just IDs, the result will contain cache tags like: ['et_a:id_a', 'et_b:<id 0>', 'et_b:<id 1>', ...]
* when entity et_b:<id 0> is updated or deleted, an invalidation is emitted for et_b:<id 0>, and the result is therefore invalidated and refreshed, so no problem here
* however when new entities in et_b are created, this result needs to be invalidated too, because new results might be part of the list, but there is no way to relate a new et_b:<id n> entity to that list
* the typical solution for this will be to manually add a tag like et_b_list to the API result (see e.g. ForumBlockBase::getCacheTags()), because every et_b CRUD operation will invalidate et_b_list
* a better scenario would be the ability to add the query instance itself as a cacheable dependency to the result. In initial, basic cases, the cache tags would probably just be ['<entity_type>_list'] based on the fact that entity queries are based on an entity type.
This would allow result building code to apply a more consistent mechanism, adding the query as a cacheable dependency, without having to explicitly know the format of its tags.
In the longer term, it would also pave the path to more sophisticated tags, because they could be generated automatically and become more opaque, removing the temptation to craft them by hand at the application level.