Re: DB_Schema or the future of datastores in PEAR

Hi Hans, Hans Lellelid wrote: [...] > 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. Well, perhaps naming it DB_Schema does limit the scope of the package, but i feel you can use the very same logic for storing -- in a structured manner -- some of the logic you use on you data (i.e. how you validate it). What I mean is that there could be a core package to extend specific functionality, being that DB-wise, Validation-wise, or otherwise. Do I make any sense? 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? How about Structure_XX ? if it incorporates non DB-specific functionality it would makes more sense for me to put it there. Finally, I hope we could set up the mailing list and coordinate all efforts since there's so many people interested in Luka's proposal. Cheers, Andrés