Description: ------------ After an upgrade of the DB package to 1.7.0RC1, the createTable.php script exits with: Warning: pg_errormessage(): supplied argument is not a valid PostgreSQL link resource in /usr/share/php/DB/pgsql.php on line 802 After some print_r'ing i've concluded that the PostgreSQL connection is lost somewhere along the way. When it first connects, the DB::connection is something like "Resource id #13" and when it calls DB_DataObject::_createTableList() it becomes "1". Again, this happened after an upgrade to DB 1.7.0RC1. Maybe the bug is in the DB class. If so i'm truly sorry.

looks alot like a DB bug.. (passing the buck).. - Daniel, any ideas..

change status

I need a simple test script that is 100% self contained. Any tables the sample script needs to run must be created by the test script. The test table must be a simple table with one or two fields. At the end of the script, the test table must be dropped.

Here's a real simple test case. It does need DB_DataObject installed, but the database it connects to need not have any tables, hence I don't create any. I couldn't find a simple breaking example which used only DB but I only tried for a half hour or so. <?php require_once('DB/DataObject/Generator.php'); $config = array ( 'DB_DataObject' => array ( 'database' => 'mysql://user:pass@localhost/test', 'schema_location' => '/tmp', 'class_location' => '/tmp', //this is incorrect, but is not used // for the generator 'require_prefix' => '/tmp', 'class_prefix' => 'DataObject_', 'quote_identifiers' => '1', ), ); $options = &PEAR::getStaticProperty('DB_DataObject','options'); $options = $config['DB_DataObject']; set_time_limit(0); DB_DataObject::debugLevel(1); $generator = new DB_DataObject_Generator; $generator->start();

Found the issue (all hail the Zend debugger!). DB_DataObject::_connect() calls serialize() to obtain DB object info in case it is needed later for debugging. DB 1.7.0RC1 added the __sleep() method, which is automatically called when PHP's serialize() is invoked. DB::__sleep() calls DB_common::disconnect(), under the common assumption that serializing the DB object is done at the end of a script in order to put the object information into a session variable for use on the next page view. Guess I'll remove the disconnect() call to avoid compatibility issues with people using serialize() for other purposes.

Aha. This is kind of DB_DataObject's fault then for serializing love objects. I've submitted Request #3640 for DB_DataObject to serialize copies instead of the live object.

Fixed in CVS.