Quello di cui stai parlando è un problema ben noto e piuttosto complesso. È noto come migrazione del database. Ogni buon progetto ha una politica che descrive come applicare lo schema del database e le mutazioni dei dati per passare da una versione del prodotto all'altra.
Molti framework come Django o Ruby on Rails hanno un sistema di migrazione integrato o disponibile come plug-in. Il tuo caso con SQLAlchemy ha poche opzioni:
- Non utilizzare alcun sistema. Basta scrivere un
/tmp/migrate.sql con le mani, annotare le istruzioni ALTER/DROP/CREATE, incrociare le dita e applicarlo alla base SQLite. In genere è una cattiva idea poiché è soggetta a errori, ma la scelta spetta a te. L'assenza dell'istruzione ALTER TABLE con tutte le funzionalità potrebbe essere aggirata creando una nuova colonna con le proprietà desiderate con nome temporaneo, copiando tutti i dati dalla colonna originale, rimuovendo la colonna originale e rinominando la nuova colonna con il nome originale. La stessa tecnica potrebbe essere utilizzata a livello di tavolo.
- Utilizzare alcuni sistemi di migrazione di terze parti come liquibase. Liquibase è bello, ben progettato e potente, tranne uno svantaggio. È davvero buggy. L'ho provato per SQLite (e sì per SQLAlchemy, ma in realtà non importa), e non è riuscito a fare alcune cose piuttosto semplici. Ho cercato su Google un problema e ho scoperto che si tratta di bug noti.
- Usa la migrazione di SQLAlchemy che hai menzionato. Non è potente come le migrazioni ROR da cui è stato ispirato, né è potente quanto il liquibase ma funziona. La limitazione di SQLite potrebbe essere aggirata nello stesso modo.
E hai chiesto informazioni su cosa eseguirà la migrazione di SQLAlchemy se tenterai di eliminare una colonna. Bene, cancellerà una colonna e quindi cancellerà tutti i dati che ci sono dentro. Altre colonne nella tabella saranno lasciate intatte.