What you're talking about is a well known and quite complex problem. It is known as database migration. Every good project have some policy that describes how database schema and data mutations should be applied to advance from one product version to the other.
Many frameworks such as Django or Ruby on Rails have a migration system built-in or available as a plug-in. Your case with SQLAlchemy has few options:
- Do not use any system. Just write a
/tmp/migrate.sql
by hands, write down ALTER/DROP/CREATE statements, cross the fingers and apply it to your SQLite base. It is generally a bad idea since it is error-prone, but the choice is up to you. Absence of full-featured ALTER TABLE
statement could be worked around by creating new column with desired properties with temporary name, copying all data from original column to it, removing original column, and renaming new column to the original name. The same technique could be used at table-level.
- Use some 3rd-party migration system such as liquibase. Liquibase is cool, well designed and powerful, except one drawback. It is really buggy. I tried it for SQLite (and yes for SQLAlchemy, but it doesn't matter actually), and it failed to do some pretty basic things. I googled for a problems and found that they are known bugs.
- Use SQLAlchemy-migrate you've mentioned. It is not as powerful as ROR-migrations which it was inspired by, neither it is as powerful as liquibase but it works. SQLite limitation could be worked around in same way.
And you've asked about what SQLAlchemy-migrate will do if you'll try to delete a column. Well, it will delete a column and so delete any data that was in it. Other columns in table will be left intact.