that's the correct approach to this, but you need to be careful of
things like foreign key constraints and the like if those are
involved. as far as how you send the "CREATE TABLE" / "DROP TABLE "
commands to the database, it doesn't matter if you use an Alembic
migration or not, the only reason having a migration present there is
if you need to run those same migrations on other databases that move
through the same state transitions. Since this is more of a
table-shrinking operation it's just as well to do this with a
standalone script that's not related to your fixed Alembic migrations.
If you aren't changing the ultimate schema it should not require any
change to your SQLAlchemy models.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy-alembic" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
sqlalchemy-alem...@googlegroups.com.
> For more options, visit
https://groups.google.com/d/optout.