On Sun, Apr 22, 2012 at 6:36 PM, Greg Sabino Mullane greg@endpoint.com wrote:
Platonides wrote:
Note we will also need a way to generate a SQL from that (eg. for manually creating a new database with SQLAdmin).
Personally, I prefer viewing the code (SQL) which is really used, but I won't stop you from making the perfect abstraction.
Well, the very first task of the new system will be to generate a tables.sql and make sure it matches the current one. Perhaps we can even keep them around, but make them "read only", for the benefit of circumstances like the above (as well as making it easy to read from the perspective of each database-in-question).
That part is pretty easy, and I actually got as much done when I worked on the feature before. It's actually really trivial to come up with some kind of abstract representation of the tables (I used PHP arrays) that class-specific implementations can then use to make a working tables.sql.
The hard part is coming up with a "this is what I have, this is what I want, so how do I get from A -> B?" Not having a clear solution to that is what made me end up shelving the project the first time.
The only question in my mind at the moment is do we also copy all the comments to each tables.sql (see maintenance/tables.sql), no comments (see oracle|postgres/tables.sql) or something in the middle (see mssql/tables.sql)?
If we're auto-generating a schema, I think putting comments there are pretty useless. They should be documented at the abstract level and on mediawiki.org.
-Chad