Re: DB_Schema or the future of datastores in PEAR

Hi Lukas, I'm interested in being on the new DB_Schema mailing list. Lukas Smith wrote:

... create an OO representation of common datastore structure elements. These OO representations would also allow creation and modifying of the datastore config within PHP. This is exactly how Propel works. The propel.engine.database.model.* classes are the OO pieces that make up a database definition (Table, Column, ForeignKey, Index, Unique, etc.). The propel.engine.database.transform.* classes use those models to parse XML, create XML from DB metadata, etc. The generator part of Propel consists of these model classes, transformation classes, and Phing tasks for fitting it into a buildfile -- and can easily be separated out from the runtime Propel classes.

Propel certainly isn't the only solution for this, but it does sound like much of DB_Schema already exists in the Propel codebase. It would be my hope that you would take what fits rather than re-invent the wheel on this. Propel is licensed LGPL, which I understand is acceptable for inclusion within PEAR.

This would enable DB_Schema to be to connecting class between a general definition of a datastore and other classes such as: - Class to manipulate structure of a database - Class to manipulate contents of a database - Class to generate forms - Class to validate input IMHO providing a schema that supports form generation or data validation (other than basic not null / type validation) is moving far beyond a schema that represents datastore structure. There are applications out there that do this also. E.g. Combine (http://combine.tigris.org) provides a PHP4 solution based on Turbine (and Torque). Also Binarycloud's Entity definition format aims at encapsulating a very rich version of entity. Perhaps it's a naming issue; when I see DB_Schema I think of something like what Propel provides, i.e. a schema that represents a database. Something that can be used to specify (e.g.) pluggable validation modules or form generation templates, sounds more like a rich entity defintion -- like Binarycloud's EDF. Importantly BC's EDF is also not SQL-specific. Maybe this package should be called "Entity" -- or "DB_Entity" if it's going to be database-specific?

Hans