I\'m beginning to incorporate Alembic into my project which already uses SQLAlchemy table definitions. At present my DB schema is managed external to my application, and I w
One of the reasons for using something like SQLAlchemy is DB independence (apart from the ORM stuff).
However, using low-level constructs like this which are often very DB specific make "DB independence" a non-argument, so I would opt for writing a simple op.execute in your alembic migration.
This is often a very acceptable trade-off as it makes the source code much simpler and this less error-prone.
If you are relying on features of a DB which are only available in one DB-backend (another example might be ltree or hstore from PostgreSQL), then I don't see any issue in using a migration which will also only work on that targeted back-end.
So you could just do:
def upgrade():
op.execute("CREATE DOMAIN ...")
def downgrade():
op.execute("DROP DOMAIN ...")
If on the other hand you plan on supporting different back-ends this won't work.