То, о чем вы говорите, является хорошо известной и довольно сложной проблемой. Это называется миграцией базы данных. У каждого хорошего проекта есть некоторая политика, которая описывает, как схема базы данных и мутации данных должны применяться для перехода от одной версии продукта к другой.
Многие фреймворки, такие как Django или Ruby on Rails, имеют встроенную систему миграции или доступны в виде плагина. В вашем случае с SQLAlchemy есть несколько вариантов:
- Не используйте никакие системы. Просто напишите
/tmp/migrate.sql
руками, запишите операторы ALTER / DROP / CREATE, скрестите пальцы и примените его к своей базе SQLite. Как правило, это плохая идея, так как она подвержена ошибкам, но выбор за вами. Отсутствие полнофункционального оператора ALTER TABLE
можно обойти, создав новый столбец с требуемыми свойствами с временным именем, скопировав в него все данные из исходного столбца, удалив исходный столбец и переименовав новый столбец в исходное имя. Тот же метод может быть использован на уровне таблицы.
- Используйте некоторые сторонние системы миграции, такие как liquibase . Liquibase - крутой, хорошо продуманный и мощный, за исключением одного недостатка. Это действительно глючит. Я попробовал это для SQLite (и да для SQLAlchemy, но на самом деле это не имеет значения), и он не смог сделать довольно простые вещи. Я погуглил проблемы и обнаружил, что это известные ошибки.
- Используйте упомянутую выше SQLAlchemy-migrate. Он не такой мощный, как ROR-миграции, которым он был вдохновлен, и не такой мощный, как жидкая база, но он работает. Ограничение SQLite можно обойти аналогичным образом.
И вы спросили, что будет делать SQLAlchemy-migrate, если вы попытаетесь удалить столбец. Ну, это удалит столбец и удалит все данные, которые были в нем. Другие столбцы в таблице останутся без изменений.