Home » Database » DB_DataObject » Bug #4203

[2005-04-22 08:18 UTC] ej dot grace at imperial dot ac dot uk

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]

[2005-05-04 06:06 UTC] daniel at konczyk dot net

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

[2005-08-20 20:47 UTC] detunizedgravity at yahoo dot fr

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?

[2005-08-21 08:55 UTC] detunizedgravity at yahoo dot fr

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.

[2005-09-30 06:32 UTC] rlwixson at thoughtprocess dot net

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.

[2005-10-02 20:28 UTC] rlwixson at thoughtprocess dot net

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.