Bug #16694
closed
Extension manager fails in a postgres environment with multiple schema's and tables.
0%
Description
Attempting to install any extension that works with tables errors out with:
Fatal error: Call to a member function MetaType() on a non-object in /var/www/typo3/typo3_src-4.0.2/typo3/sysext/dbal/class.ux_t3lib_db.php on line 1096
This is caused in the end by:
typo3/sysext/dbal/class.ux_t3lib_db.php line 1088, function MetaType
which is called by:
typo3/sysext/dbal/class.ux_t3lib_db.php line 1734, function admin_get_fields
which is called by:
t3lib/class.t3lib_install.php line 411, function getFieldDefinitions_database
which is called by:
typo3/mod/tools/em/class.em_index.php line 4371, function checkDBupdates
The function checkDBupdates:
Validates the database according to extension requirements. Prints form for changes if any. If none, returns blank. If an update is ordered, empty is returned as well. DBAL compliant (based on Install Tool code).
The function getFieldDefinitions_database calls admin_get_tables which gets all the tables and iterates over them. This function should iterate over the list of tables WITH the schema prefix added.
function admin_get_tables (typo3/sysext/dbal/class.ux_t3lib_db.php, 1649), calls (in case of adodb):
$sqlTables = $this->handlerInstance['_DEFAULT']->MetaTables('TABLES');
So . . . . . in case of postgres . . . . the MetaTables function:
typo3/sysext/adodb/adodb/drivers/adodb-postgres64.inc.php, line 209:
Executes:
select tablename,'T' from pg_tables where tablename not like 'pg\_%'
and schemaname not in ( 'pg_catalog','information_schema')
union
select viewname,'V' from pg_views where viewname not like 'pg\_%' and schemaname not in ( 'pg_catalog','information_schema')
This returns a list of all tables that the current connection user may view.
The problem here is that TYPO3 was installed by default in the 'public' schema. Tables herein may be queried without using the schema prefix 'public'.
The function MetaType does a SELECT from a table (without prefix). But a table has been added to a different schema (for example contacts.organisations) within the same database as TYPO3 was installed into.
In our case this results in three tables also viewable: origanisations, persons and organisations_persosn. These three tables reside in the 'contacts' schema however.
Because of all this the SQL SELECT query in MetaType() will fail.
Solution: allways take the schema into account when getting table listings and doing table operations.
(issue imported from #M4472)
Files
Updated by Olivier Dobberkau over 16 years ago
We experience this bug too.
It seems that nobody has really tested dbal somehow...
yuks..
Olivier
Updated by Michiel Roos over 16 years ago
I know . . .
I need to set up my test site here @ work on top of postgres, maybe I can dig up some more bugs.
In Karlsruhe last year I promised Karsten do help test the dbal. So far I only tested it on postgres. We ran a successfull install on postgres. I am not sure if this bug is still present in 4.1.2
Can you post some more details about your environment?
Updated by Olivier Dobberkau over 16 years ago
Our Setup:
TYPO3 Version 4.1.2
On Debian Etch.
Postgres 8.1 on another Host running Ubuntu.
The Ext Manager is not working correctly...
Updated by Christian Trabold over 16 years ago
I investigated this issue a bit and found a way to get the extension-manager and Database Analyser in Install-Tool to work again (see attached patch file for "class.ux_t3lib_db.php").
This error message occurs only if mapping external tables into TYPO3 is active (mapping to tables with a different handlerCfg). So, this config throws an error:
$TYPO3_CONF_VARS['EXTCONF']['dbal'] = array(
'handlerCfg' => array (
'_DEFAULT' => array (
'type' => 'adodb',
'config' => array (
'driver' => 'postgres8',
)
),
'external_table' => array (
'type' => 'adodb',
'config' => array (
'driver' => 'postgres8',
'username' => 'username',
'password' => 'password',
'host' => '192.168.0.2',
'port' => '5432',
'database' => 'database_name',
)
),
),
'table2handlerKeys' => array(
'tt_address' => 'external_table',
),
'mapping' => array(
// This is mapping for external DB-Tables
'tt_address' => array(
'mapTableName' => 'ext_tt_address',
'mapFieldNames' => array(
'uid' => 'ext_id',
'pid' => 'ext_pid',
'name' => 'ext_name',
'company' => 'ext_company',
'hidden' => 'ext_hidden',
'deleted' => 'ext_deleted',
'tstamp' => 'ext_tstamp',
),
),
// This is mapping for internal TYPO3-Tables
'be_groups' => array(
'mapFieldNames' => array(
'groupMods' => 'groupmods',
'lockToDomain' => 'locktodomain',
'TSconfig' => 'tsconfig'
),
),
),
);
?>
while this works perfectly:
$TYPO3_CONF_VARS['EXTCONF']['dbal'] = array(
'handlerCfg' => array (
'_DEFAULT' => array (
'type' => 'adodb',
'config' => array (
'driver' => 'postgres8',
)
),
'external_table' => array (
'type' => 'adodb',
'config' => array (
'driver' => 'postgres8',
'username' => 'username',
'password' => 'password',
'host' => '192.168.0.2',
'port' => '5432',
'database' => 'database_name',
)
),
),
'table2handlerKeys' => array(
'tt_address' => 'external_table',
),
'mapping' => array(
// This is mapping for internal TYPO3-Tables
'be_groups' => array(
'mapFieldNames' => array(
'groupMods' => 'groupmods',
'lockToDomain' => 'locktodomain',
'TSconfig' => 'tsconfig'
),
),
),
);
?>
After the patch, I was able to compare tables in Install-Tool with the Database Analyser and install Extensions that create new tables in TYPO3 (eg. tt_news), which is great, but I'm a affraid that this is not the real fix for the problem yet.
So more tests and investigations have to be done on this.
Michiel, could you test the patch and post a note here, what changed in your installation? Thanks!!
Greetings
Christian
Updated by Michiel Roos over 16 years ago
Hi Christian,
Currently I don't have a running postgres environment an I am busy on other projects (sorry). . .
I am not sure that your problem/solution have anything to do with postgres 'schema'.
If you can, please run your problem + solution by Karsten Dambelkans. He's the DABAL guru.
Kind regards,
Michiel Roos
Updated by Ries van Twisk over 14 years ago
Did any of you guys tried to set a search path to each schema?
Second, I think all of teh above is solved in latest DBAL.
Ries
Updated by Michiel Roos over 14 years ago
Hi Ries,
No, I did not try that. Is that documented somewhere in the dbal docs?
If you think all is solved in the latest dbal, please close the bug.
Kind regards,
Michiel
Updated by Ries van Twisk over 14 years ago
Michiel,
it's a PostgreSQL setting for it's role.
Ries
Updated by Xavier Perseguers about 14 years ago
Hi there, any news for this bug? I tried to start debugging DBAL too on PostgreSQL but I'm quite still stuck to MySQL, Oracle and MSSQL thus...
Updated by Michiel Roos about 14 years ago
Hi,
I haven't tried lately. Ries, have you had TYPO3 running the extension manger without problems? Then this bug can probably closed. It would be nice if the setting a search path for each schema would be documented somewhere in the WIKI.
Updated by Alexander Opitz almost 11 years ago
- Status changed from New to Closed
- Target version deleted (
0) - TYPO3 Version set to 4.1
No response in over one year => closed.