> 4\. Better safe than sorry. I've deliberately removed the migration > capabilities like add column, remove, rename table, etc. Turns out, > migrations are never trivial, and it's always better to just write SQL > manually than to try to automate it somehow.
That's very true. However, even if there is no automatic migration, it is helpful to have a tracking of which schema is in the database and which one is expected by the code. As you generate a DDL statement that creates the tables (and in the future - maybe also indices, and/or triggers, and/or stored procs), perhaps you can use a sha1 of that statement to "name" the created/expected model, and then -- perhaps with a helper table that names the existing schema, you can verify whether the data model matches. Migration from one schema to a another should NOT be within the scope of the main ORM in my opinion -- however, it is useful if versions of the software can ship with "migrate-HASH1-to-HASH2" scripts, many of which will be trivial -- and the applicator of which CAN be included with the ORM. Just my thoughts and experience, mostly from using web2py (nowadays py4web) which made a lot of controversial choices, some good and some bad -- and most of those related to migration have a lot to teach by being bad ....
