PEAR is discontinued

This is a static archive preserving historical releases and metadata. No new packages or updates will be published. For updates to existing packages, or to publish new packages, please use Composer and Packagist.

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