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)    
Subscription  


 [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 ?)

Comments

 [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'); < }
 [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 pear.php.net. In case this was a pear.php.net 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) 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