Project

General

Profile

Actions

Bug #16221

closed

Extension tables created on wrong database

Added by Torkil Svensgaard almost 18 years ago. Updated almost 18 years ago.

Status:
Closed
Priority:
Should have
Category:
Database API (Doctrine DBAL)
Target version:
-
Start date:
2006-06-08
Due date:
% Done:

0%

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

Description

My installation was created from scratch with DBAL, following the instructions at http://typo3.org/documentation/document-library/extension-manuals/dbal/current/view/1/4/

The DBAL specific part of typo3conf/localconf.php is included as additional information.

The problem arises when installing extensions which require database changes. More often than not, the installer creates extension tables in the "arpac" database instead of using "_DEFAULT".

When looking at the installed and running extension, it always requests an update to the database (likely because it can't find the table in the _DEFAULT database) but when the update is executed, it's on the wrong database, leaving me at square one.

It is not neccesarely every time, as about 50% of my installed extensions have their tables in "_DEFAULT" and the rest in "arpac".

Any other information required or is this a feature of some sort?

$TYPO3_CONF_VARS['EXTCONF']['dbal']['handlerCfg'] = array (
'_DEFAULT' => array (
'type' => 'adodb',
'config' => array(
'driver' => 'mysql',
)
),
'arpac' => array (
'type' => 'adodb',
'config' => array(
'username' => '***',
'password' => '***',
'host' => 'localhost',
'database' => 'Arpac_dbo_test',
'driver' => 'mysql',
)
),
);

$TYPO3_CONF_VARS['EXTCONF']['dbal']['table2handlerKeys'] = array (
'Candidate' => 'arpac',
'CountryCode' => 'arpac',
);

$TYPO3_CONF_VARS['EXTCONF']['dbal']['debugOptions'] = array(
'enabled' => true, // Generally, enable debugging.
'printErrors' => FALSE, // Enable output of SQL errors after query ex
ecutions.
'EXPLAIN' => 1, // EXPLAIN SELECT ...(Only on default handler)
'parseQuery' => 1, // Parsing queries, testing parsability (All q
ueries)
'joinTables' => 1
);
(issue imported from #M3638)

Actions #1

Updated by Karsten Dambekalns almost 18 years ago

Using localhost for differtn handlers doesn't work. Although the DBAL internally has two different resource handles for the connections, PHP connects top the wrong one.

Try using localhost for one connection and another hostname pointing to the same IP for the second.

Actions #2

Updated by Torkil Svensgaard almost 18 years ago

Thanks, changing the hostname seems to have done the trick.

Actions #3

Updated by Karsten Dambekalns almost 18 years ago

Following ~8949 I added this flag to the connect call. It will only work if one manually switches TYPO3 to not use pconnect, though.

(The changes are not yet in CVS)

Actions #4

Updated by Karsten Dambekalns almost 18 years ago

I added some hint about this topic to the manual of the upcoming version.

Actions

Also available in: Atom PDF