Description: ------------ Updating to the newer version of DB::DataObject breaks the generation of the [database].ini file describing the data objects. 1) It now no longer correctly identifies the keys of a table 2) It now prefixes the tables with the schema "public.". In principle this is not a great problem, it just means renaming things Reproduce code: --------------- Using an older version createTables.php would generate the (correct) ini file: Create a table using the SQL: --- Database schema for ejournal database ---- DROP TABLE country; CREATE TABLE country ( id BIGINT DEFAULT nextval('country_seq') NOT NULL, code CHAR(2) NOT NULL, name VARCHAR(255) NOT NULL, UNIQUE (code), PRIMARY KEY ( id ) ); DROP SEQUENCE country_seq; CREATE SEQUENCE country_seq; Create DataObjects.ini like so, [DB_DataObject] database = pgsql://user:password@host/database schema_location = /home/user/DataObjects class_location = /home/user/DataObjects require_prefix = /home/user/DataObjects/ class_prefix = DataObjects_ debug = 3 Execute /usr/bin/php /usr/share/pear/DB/DataObject/createTables.php /home/user/DataObjects.ini [public.country] id = 1 code = 2 name = 2 [public.country__keys] Expected result: ---------------- I would expect the same behaviour as in earlier versions of DB::DataObject, namely the generation of database.ini containing [country] id = 129 code = 130 name = 130 [country__keys] id = N Actual result: -------------- Note, the prefix of the schema (unwanted, but can be lived with), the incorrect identification of id, code and name (they are all required, NOT NULL) and the empty list of keys. [public.country] id = 1 code = 2 name = 2 [public.country__keys]

right, this is actually very annoying bug!!! alan,please fix it in cvs. forcing to use chema.tablename is totally useless, when one use default schema which is 'public'. No, after I recreated the data with generator, I have everything different. I searched, why there are no keys in the .ini file anymore and I found, that when you call tableInfo with schema.tablename as a parameter instead of just tablename, then the flag values for each column of that table are empty! when you call this function with tablename, the flags are correct. so either make this 'using schema.tablename' an option with default to false or just remove it as it is not working correctly that's what i did in the Generator.php - commented that line out... thanks

The schema part is fixed in cvs (option: generator_strip_schema=1), the keys appears to be a DB problem, still investigating.

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.

The problem is still present in DB_DataObject version 1.7.16, just tested on a Debian x86 box. The bug is reproducible with both PHP 4.3.10 and 5.0.4 (not that it matters if I understood well). I still find the faulty code in Generator.php (see the "diff" output in Bug #4235), and I am stuck with the same problem as nicosolaris, which makes DataObject useless for me as of now. As far as I am concerned, *this bug is everything but "closed".* Has there been a regression somewhere between 1.7.14 and 1.7.16?

I made a little mistake in my previous comment: the version of DB_DataObject I use is 1.7.15, not 1.7.16. It is the latest available stable version according to "pear" on my box.

I am also experiencing the pain of this bug. (applicable) Installed packages: =================== Package Version State DB 1.7.6 stable DB_DataObject 1.7.15 stable Date 1.4.3 stable PEAR 1.4.1 stable postgres 7.4.7 and php4.4.0 from debian. $generator = new DB_DataObject_Generator; $generator->generator_strip_schema = 1; $generator->start(); Running the generator I get an ini file like this... ---------------------- [public.orders] orderid = 1 custid = 1 order_xml = 34 order_date = 1 status = 2 [public.orders__keys] ---------------------- With no keys, and the schema name still prefixing the table, although I'm not sure I used generator_strip_schema properly because it is not documented anywhere. I am an avid user of PEAR, and DB_DataObject in particular, but usually with MySql, not PgSql. What has happened to the reported fixes??? Please Alan. Help us out. If the fix is already done, then please see that it is released. Thank you for this excellent package.

this will not work: $generator = new DB_DataObject_Generator; $generator->generator_strip_schema = 1; $generator->start(); just add this line to the .ini file that is used to generate the classes/schema. generator_strip_schema = 1

Thanks Alan. I added 'generator_strip_schema' => 1, to the options static property array... $do_options = &PEAR::getStaticProperty('DB_DataObject','options'); $do_options = array( 'database' => $strDSN, 'schema_location' => './../DataObjects', 'class_location' => './../DataObjects', 'require_prefix' => 'DataObjects/', 'class_prefix' => 'DataObjects_', 'generator_strip_schema' => 1, ); The 'public' schema was stripped off of the generated class files, and the keys are now defined in the .ini file. For example... [vendors] vid = 129 vcode = 2 vname = 2 keep = 1 [vendors__keys] vid = K So things are looking much better. I have a few questions. 1) Is this not what one would consider to be the default expected behavior for using the generator on a pgsql database? If so, then why not make this the default option for the generator under those conditions? 2) Is this option 'generator_strip_schema' ONLY necessary for generation, and will it have any effects if left in, or removed from, the options array during normal (production) use? Also, could the end user documentation 'Configuration Options' http://pear.php.net/manual/en/package.database.db-dataobject.intro-configuration.php be updated in order to help other pgsql users of this package? Thanks again.