[TYPO3-v4] Current master branch is broken?

[Ernesto Baschny [cron IT]]

Christian Kuhn schrieb am 28.06.2011 16:41:
> Hey,
> 
> On 06/28/2011 04:09 PM, Ernesto Baschny [cron IT] wrote:
>> I have no clue about this specific problem, and have not followed the
>> caching framework latest development
> 
> Some explanations to the whole thing:
> The cf db backend had the problem that if extensions define own caches
> with this backend they had to add the needed table structure to their
> ext_tables.sql for the tables (data + tags). This made it effectively
> impossible for core to change the layout of the table structure because
> extensions had to catch up with this. So we had a dependency from core
> to extensions, which is bad.
> 
> Therefore recent db backend changes did the following:
> - Table definition is handled by the backend itself (there are template
> sql files).
> - Table names are constructed from the (unique) cache name and prefixed
> with 'cachingframework_'.
> - If flushing a cache with db backend, additional to the 'truncate' the
> tables are dropped and created with defined layout again. (=> zero
> overhead in production).
> - The install tool db analyzer was changed to ignore all tables that are
> prefixed with 'cachingframework_'
> 
> So, in effect, the db backend now takes care of needed db structure on
> its own. This allows us to change the structure however we need without
> any dependencies to extensions (and extensions do not need to declare
> table structure and naming things).
> 
> I thought that flush() would do the trick (because on upgrading usually
> every user flushes caches at least once), but looking at Dmitry's login
> issue it might be better to just check with mysql_error() at more place
> and upgrade table definition silently if some query failed (I'll think
> about this a bit and will come up with a patch if it turns out to be a
> clever solution).
> 
> So thanks for your report Dmitry, I was unaware that the 'update tables
> on flush()' method could fail because a login is impossible. Anyway, a
> simple upgrade wizard that just calls cacheManager->flushCaches() and
> deletes temp_CACHED* should be created, too.

Thanks for the explanation, Christian, I like the way it is dealt with.
Letting Core take care of the caching tables makes a lot of sense. For
older extensions which ship with their own layout, those will simply be
"ignored" on 4.6 and on, right?

Fixing the upgrade path is the last missing step, and I think it was not
left undone on purpose but still in time, since we are still in Alpha phase.

Good work!

Cheers,
Ernesto