Re: [Proposal] DB_OO

Sérgio carvalho wrote:

Reducing DB_OO to the metadata classes is rather trivial. Dumping features that colide with DB_Dataobjects, we'd be left with an uniform interface to database system catalogs. There's usage for an uniform DB catalog layer outside of DB_Dataobject, so the only question that remains is: Is there any significant movement in a PEAR project towards such a library, or should I build it as a separate module?

I was going to suggest you look at the Propel project (http://propel.phpdb.org) since it does have this "DB catalog layer", if I understand your meaning. Propel is a PHP5 port of the Apache Torque object persistence framework. Propel has two [currently interwoven] compoents: 1) a generator that generates vendor-specific SQL and PHP classes, and 2) a runtime environment that transparently handes object persistence. Propel uses an abstracted (simplified) XML schema representing the DB catalog. This generic schema is converted by templates into RDBMS-specific SQL definition files (e.g. "VARCHAR" might be interpreted as "varchar2" for Oracle). The PHP classes are also generated from this schema -- including, e.g., methods that will fetch [fkey] related rows in a single query. Additionally, Creole -- the JDBC-like db abstraction package used by Propel -- has good metadata support & a unified type system (and mappings from vendors -> generic types), which allows Propel to build the catalog XML from db metadata. Of course the resulting catalog usually needs tweaking, but it does a good job mapping detailed info about tables, columns, foreign keys (when rdbms supports), primary keys, indexes, constraints... Propel (and Creole) currently supports MySQL, PostgreSQL, MS SQL Server, Oracle (still in development), and SQLite. Seems like some of this might be at least useful in your project. It's all LGPL, so I think quite compatible w/ PEAR licensing reqs (?). Cheers, Hans

Attachment: [application/x-pkcs7-signature] S/MIME Cryptographic Signature smime.p7s