PEAR is archived and read-only

This mirror preserves historical PEAR package releases and metadata so existing references remain available.

Home » Database » DB_DataObject » Bug #4235

the createTables.php script does not reconize the primary key with postgreSQL

Details

Submitted2005-04-27 17:15 UTC
Fromnicosolaris at yahoo dot fr
Assignedalan_k
StatusClosed
PackageDB_DataObject
PHP Version4.3.9
OSSolaris 5.6
Roadmaps(Not assigned)

Comments

[2005-04-27 17:15 UTC] nicosolaris at yahoo dot fr

Description:
------------
I think this is linked to bug #4203, it is a story of schema problem.

======================
Config:
======================
PEAR-1.3.5
DB_DataObject-1.7.13
DB-1.7.6

PHP 4.3.9

PostgreSQL 7.4.5

OS: Solaris 5.6

======================
Problem description:

the DataObject createTables.php script does not reconize the primary key with postgreSQL

I dig through the code, and detect where comes from the problem:

In DB/DataObject/Generator.php, a call is made with '$defs = $__DB->tableInfo($table);'
$table is equal to public.toto public is the schema.

but the function tableInfo($result, $mode = null) which is in 'DB/pgsql.php' ,
call to $this->_pgFieldFlags($id, $i, $result), which prototype is function _pgFieldFlags($resource, $num_field, $table_name)

This function make select in pg_class, but there is no public. relname in pg_class, only 'toto' relname.
this produce empty flags !

then with empty flags, DataObject cannot determine primary key !

Is it a bad call from Generator.php or does the function _pgFieldFlags in pgsql.php must take care that param can be <schema>.<tablename> ? (or is it a postgresql problem that did not store the schema in pg_class ?)

[2005-04-27 18:16 UTC] nicosolaris at yahoo dot fr

The last version where it run is DataObject 1.7.10.
Moreover, the shell generate a new naming with Public_ in front of each class .php.

Here is a diff between the Generator.php code, the select table is applied on schema.table (before it was 'table' only).

$ diff DB_DataObject-1.7.13/DataObject/Generator.php DB_DataObject-1.7.10/DataObject/Generator.php | tail -20
< * @license http://www.php.net/license/3_0.txt PHP License 3.0
< * @version CVS: $Id: Generator.php,v 1.91 2005/03/23 02:35:35 alan_k Exp $
< * @link http://pear.php.net/package/DB_DataObject
< */
<
< /**
< *
32a31,32
> * @package DB_DataObject
> * @category DB
142a143,144
>
> $this->tables = $__DB->getListOf('tables');
144,149d145
< // try getting a list of schema tables first. (postgres)
< $this->tables = $__DB->getListOf('schema.tables');
< if (empty($this->tables) || is_a($this->tables , 'PEAR_Error')) {
< //if that fails fall back to clasic tables list.
< $this->tables = $__DB->getListOf('tables');
< }

[2006-03-25 01:22 UTC] bryn at mrpath dot com

I was having similar issues to this submitter. What helped me was this email from the pear list (doesn't easily come up on google to I post it here) http://beeblex.com/lists/index.php/php.pear.general/21235?s=postgresql+db_dataobject

The solution was adding 'generator_strip_schema' => 1 to my db_dataobject.ini file so the objects were named tablename instead of Public_tablename, which made the primary keys show up in the schema .ini file