TYPO3 Core

I think this would still be a cool addition to get the caching framework more easy to use for extension developers in 4.5. Do you think you have some time to think about an easy solution?

@Christian, do you have any opinion / idea on this?

I'm unsure if that would give us a real benefit.

Here is the current situation:
- We currently have 3 core caches: pages, pagesection, hash. All of them work with two separate tables, each. This is useful and shouldn't be changed: It gives you the advantage to configure them separately, for example it's often a benefit to enable data compression for pages, but not for the other tables.
- Extensions I am aware of, which use the caching framework:
-- tt_news: I'm unsure what exactly goes into it
-- exbase: It uses the cf for a reflection cache. I have no idea if this should be mixed with other data
-- enetcache: A cache to store content element data. This should not be mixed with other data, it usually has high read and low write load and tons of tags assigned to an entry.

My point:
Each cache has it's own usage signature and should be tuned for exactly this use case. Any developer can and should deliver an extension with a sane default for his case.

If I understand right, this issue is about adding two default tables (tag and data) to gather different caches in those tables if nothing else was configured. This actually can be done, and we could even remove the other tables for pages, pagesection and hash and route it's content to this table by default.
A real problem is that the db backend currently truncates the complete table on flush() (because this is way faster than deleting each entry in a loop). This must be changed then to only delete entries of the affected cache and will lead to a massive slowdown on cache clearing. Removing the truncate from dbbackend is no option, we will need an alternative handling for cache clearing if the table is a "multi cache" table, and add logic to handle it.
BTW: That's why memcache cache clearing is so slow: memcache has no namespacing, it must first find all affected entries and delete them in a loop. That's also why redis is lightning fast on cache clearing, every cache should go to an own database, each cache is flushed with one call.

Here are the things we should do if we want a default table:
- Hack the dbbackend to add logic for a cache clearing in "multi cache usage", accepting a massive slowdown on cache clearing (estimated slowdown: At minimum O(n) in contrast to O(1) for number of affected entries, probably even worse due to the tags table).
- Add default table routing in the manager (or factory?) to route unconfigured dbbackends to this table
- Think about removing pages, pagesection and hash default table configuration and route them to this table. If we don't do this, we might end up with just two additiional db tables which are never used by the core.

All in all I have the feeling that this is not worth it, the only benefit is a little more straight localconf, and some less tables in our default configuration.

Christian, thanks for the opinion, I tend to share the same opinion. Let's see if Ingo has some other ideas or arguments about this one, else we simply close the issue again.

Hey guys,

the default table is meant for extensions only and as a default when no other specific table has been configured. Concerning cache clearing, since we're free to do what we want with the DB backend, we could of course introduce a namespace here and use that when clearing the cache...

Hey Ingo.

I still think we don't need that:
Every cache by some extension is done for some purpose. An author probably does not want to share this with other caches in the same table which can lead to unpredictable performance impact. I don't see a reason to implement a shared table space which is delivered by core, unused by core, just for extensions, and extensions shouldn't use it for performance reasons. Do you see a problem with two dedicated tables for each cache?

At the moment I see no reason in refactoring the db backend in this regard, there is no advantage. Did I miss something?

I agree that we should close this issue. The "auto-creation" of cache tables on demand is a cool solution for the "problem" (extensions don't need to create them) and we still have the flexibility we need in our core to change the definitions later.

So +1 on closing it. Christian is on the same opinion still. Ingo, any further comments?

+1 to close this.

Next time you guys ask for my feedback, it'd be cool to actually wait for it, too ;)

... even if I agree with dropping the issue... :)