On Sun, Apr 22, 2012 at 6:36 PM, Greg Sabino Mullane <greg(a)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