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