Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.11.5

Bug #4235 the createTables.php script does not reconize the primary key with postgreSQL
Submitted: 2005-04-27 17:15 UTC
From: nicosolaris at yahoo dot fr Assigned: alan_k
Status: Closed Package: DB_DataObject
PHP Version: 4.3.9 OS: Solaris 5.6
Roadmaps: (Not assigned)    

 [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 PHP License 3.0 < * @version CVS: $Id: Generator.php,v 1.91 2005/03/23 02:35:35 alan_k Exp $ < * @link < */ < < /** < * 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'); < }
 [2005-05-04 13:33 UTC] alan_k
can you provide a sql create table code so I can test postgres with various schemas.
 [2005-05-04 14:13 UTC] alan_k
This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on In case this was a website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better. reopen if it's still broken.
 [2006-03-25 01:22 UTC] bryn at mrpath dot com (bryn)
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) 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