Bug #89459

Exception due to missing cache tables on Upgrade from 9.5 to TYPO3 10.1

Added by Sybille Peters over 1 year ago. Updated about 1 month ago.

Status:
Needs Feedback
Priority:
Should have
Assignee:
-
Category:
Install Tool
Target version:
-
Start date:
2019-10-19
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

 Doctrine\DBAL\Exception\TableNotFoundException
An exception occurred while executing 'SELECT `content` FROM `cache_rootline` WHERE (`identifier` = ?) AND (`expires` >= ?)' with params ["1__0_-99", 1571466118]: Table 't3intro.cache_rootline' doesn't exist

When I look in the database tables of my TYPO3 9 installations I see only

| cf_cache_hash                               |
| cf_cache_hash_tags                          |
| cf_cache_imagesizes                         |
| cf_cache_imagesizes_tags                    |
| cf_cache_pages                              |
| cf_cache_pages_tags                         |

no cache_hash etc.

Changelog: https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/10.0/Deprecation-88366-DefaultCachingFrameworkCacheNamesChanged.html

#1

Updated by Georg Ringer over 1 year ago

  • Status changed from New to Needs Feedback

did you do a DB compare to get those tables?

#2

Updated by Sybille Peters over 1 year ago

  • Subject changed from Exception due to missing cache tables on Upgrade to TYPO3 10.1 to Exception due to missing cache tables on Upgrade from 9.5 to TYPO3 10.1
#3

Updated by Sybille Peters over 1 year ago

  • Status changed from Needs Feedback to Closed

Sorry, my bad. Indeed, I had to do a DB compare first.

#4

Updated by Maximilian Winck 2 months ago

I ran into this issue.

After upgrading, I got an exception when visiting the backend due to missing cache tables. To get rid of the exception and access the backend, I disabled all caches via `AdditionalConfiguration.php`:

foreach ($GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations'] as $cacheName => $cacheConfiguration) {
    $GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations'][$cacheName]['backend'] = \TYPO3\CMS\Core\Cache\Backend\NullBackend::class;
}

But this causes the Database Analyzer to not want to create the cache tables in the first place.

The only way to fix it was visiting the Database Analyzer in the install tool directly (not through backend) while the caches were not disabled.

This took me a while to figure out, because I initially assumed the direct-access install tool was gone: I couldn't access it via `/typo3/install` anymore, only via `/typo3/install.php`.

#5

Updated by Sybille Peters 2 months ago

  • Status changed from Closed to Needs Feedback

So, this was when updating to 10? For completeness sake, can you add the text of your exception message and the steps you performed?

I think this may actually not be a bug but just a question of how the upgrade must be performed and in which order. We might want to add a warning to the docs, e.g. in https://docs.typo3.org/m/typo3/guide-installation/10.4/en-us/Upgrade/Index.html

#6

Updated by Stephan Boiting about 2 months ago

my solution sql:

CREATE TABLE `cache_rootline` (
`id` int(10) UNSIGNED NOT NULL,
`identifier` varchar(250) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
`expires` int(10) UNSIGNED NOT NULL DEFAULT 0,
`content` longblob DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `cache_hash` (
`id` int(10) UNSIGNED NOT NULL,
`identifier` varchar(250) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
`expires` int(10) UNSIGNED NOT NULL DEFAULT 0,
`content` longblob DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `cache_hash_tags` (
`id` int(10) UNSIGNED NOT NULL,
`identifier` varchar(250) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
`tag` varchar(250) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `cache_rootline_tags` (
`id` int(10) UNSIGNED NOT NULL,
`identifier` varchar(250) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
`tag` varchar(250) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `cache_pagesection` (
`id` int(10) UNSIGNED NOT NULL,
`identifier` varchar(250) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
`expires` int(10) UNSIGNED NOT NULL DEFAULT 0,
`content` longblob DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

CREATE TABLE `cache_pagesection_tags` (
`id` int(10) UNSIGNED NOT NULL,
`identifier` varchar(250) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
`tag` varchar(250) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `cache_pages` (
`id` int(10) UNSIGNED NOT NULL,
`identifier` varchar(250) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
`expires` int(10) UNSIGNED NOT NULL DEFAULT 0,
`content` longblob DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `cache_pages_tags` (
`id` int(10) UNSIGNED NOT NULL,
`identifier` varchar(250) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
`tag` varchar(250) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

#7

Updated by Maximilian Winck about 1 month ago

Sybille Peters wrote in #note-5:

So, this was when updating to 10? For completeness sake, can you add the text of your exception message and the steps you performed?

I think this may actually not be a bug but just a question of how the upgrade must be performed and in which order. We might want to add a warning to the docs, e.g. in https://docs.typo3.org/m/typo3/guide-installation/10.4/en-us/Upgrade/Index.html

IIRC the only steps needed to trigger the "issue" is switching a v9.5 installation to v10.4 - I do it via changing the typo3_src symlink. Then try to visit the backend, it will trigger an exception immediately, because the database was not yet updated to v10.4.

As I said, my main mistake was not using the install tool directly (because I failed to realize that the URL is `/typo3/install.php` and not `/typo3/install`).

The Docs do say to use the install tool here, at the top: https://docs.typo3.org/m/typo3/guide-installation/10.4/en-us/Upgrade/UseTheUpgradeWizard/Index.html
Arguably, it's easy to overlook. What would definitely have helped me is if the backend just redirected to the install tool directly upon detecting that the Database had not yet been updated with the Database Analyzer, instead of throwing an exception.

Also available in: Atom PDF