TYPO3 Core

from the docs

It's highly recommended to prepend all custom fields and tables with the prefix “user_”. Not only will this prefix never be used for any default tables and fields, but the prefix is also recognized by the Install Tool thus warning you that this table or field is apparently a user-added field or table and thus should not be removed during updates of the database structure:

IMO this is the way to go

ich tried that, but in 4.5 / 4.6, the installtool still suggests me to prepend the tablename with "zzz_deleted_" and remove the tables afterwards:

e.g.

(USER) ALTER TABLE user_piwikintegration_user_language RENAME zzz_deleted_user_piwikintegration_user_language;

my goal is to hide specific tables in the "database compare" dialogue!

http://typo3.org/documentation/document-library/tutorials/doc_tut_frontend/0.0.1/view/2/5/#id3927281

Furthermore, not all 3rd party applications allow renaming tables to "user_*" and it would be great if extensions can configure prefixes of excluded tables in ext_tables.php or a similar file, e.g.

array('mshop_', 'madmin_' );

to exclude all tables that start with "mshop_" or "madmin_".

see https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Database/ConnectionPool/Index.html

Most integrators already do this but for tables that have foreign key contstraints to fe_users this doesn't work.

Hi all,

i needed this for a 8.7 setup now, and this seems to do the trick in my ext_localconf.php

\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\Database\ConnectionPool::class)
    ->getConnectionByName(\TYPO3\CMS\Core\Database\ConnectionPool::DEFAULT_CONNECTION_NAME)
    ->getConfiguration()->setFilterSchemaAssetsExpression('/^(?!(prefix1|prefix2)\_).*$/');

In newer versions, the regex is deprecated and replaced by a callback based filter https://github.com/doctrine/dbal/pull/3308

HTH
Andreas

The solution in unfortunately #17 is not perfect. It tells doctrine to ignore these tables, but makes TYPO3 then try to newly create this tables, because it couldn't be "found" in the schema. Which will then lead to another error:
Base table or view already exists: 1050 Table 'tx_ifoobar' already exists

Christian Eßl wrote:

The solution in unfortunately #17 is not perfect. It tells doctrine to ignore these tables, but makes TYPO3 then try to newly create this tables, because it couldn't be "found" in the schema. Which will then lead to another error:
Base table or view already exists: 1050 Table 'tx_ifoobar' already exists

This does mean that TYPO3 knows the tables that you ignore for that connection, doesn't it? IHMO you shouldn't define any SQL in your extension for the tables you are using in your other connection.