Vlastimil Zíma

Sounds correct. I'm a bit lost in the terminology.

Workaround to reuse enum in backend-agnostic (I hope) case: ```python def upgrade(): connection = op.get_bind() if connection.dialect.name == "postgresql": status_enum = postgresql.ENUM('pending', 'accepted', 'canceled', name='mytable_status_enum', create_type=False) else: status_enum = sa.Enum('pending',...

Workaround based on @zzzeek's answer from sqlalchemy/sqlalchemy#5593: ```python def upgrade(): status_enum_postgres = postgresql.ENUM('pending', 'accepted', 'canceled', name='mytable_status_enum', create_type=False) status_enum = sa.Enum('pending', 'accepted', 'canceled', name='mytable_status_enum') status_enum.with_variant(status_enum_postgres, 'postgresql') op.add_column('mytable', sa.Column('status', status_enum)) ``` It...

@JohnnyFee My solution works for me at alembic 1.5.8, but I still use sqlalchemy 1.3, which may be the difference. I still encounter `type "mytable_status_enum" already exists` error, when I...

Would it be possible to add `--check` option to the `revision` command to return a non-zero exit code if a non-empty migration is generated? I admit that it's inspired by...

In my point of view, alembic is external tool for the application, so migration checks shouldn't be part of application unittests. I place them on the same level as static...

I'm glad to hear that. Here's my proposal: add `--check` option to `revision` command. It would print the differences in migrations (using logging, since alembic has no verbosity) and return...

I meant it as an optional usage. But we can resolve that when we get there.

I just encountered this issue on enum fields when resolving changes from alembic 1.7, specifically #884. I'm quite confused by contradictory information on the topic. Alembic documentation https://alembic.sqlalchemy.org/en/latest/batch.html#including-check-constraints describes how...

I use the PEP-435 `Enum` class for the column values. As I understand docs, that should be equivalent. Did I miss something else?