-
-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migration downgrade doesn't drop type created by Enum #886
Comments
hi - we are not fixing any autogenrate enum issues in the near future however when you say "downgrade is impossible" I would need to know what migration operation you are referring towards. you can drop enums manually using |
Hi @zzzeek, I'll try to be clearer. Firstly, I want to point out that I'm working on postgres. The following class definition class SomeType(enum.Enum):
foo = 'foo'
bar = 'bar'
class SomeTestTable(BaseTable):
__tablename__ = 'some_table'
id = Column(UUID(as_uuid=True), primary_key=True, default=uuid.uuid4)
some_type = Column(Enum(SomeType)) generates the following migration def upgrade():
# ### commands auto generated by Alembic - please adjust! ###
op.create_table('some_table',
sa.Column('id', postgresql.UUID(as_uuid=True), nullable=False),
sa.Column('some_type', sa.Enum('foo', 'bar', name='sometype'), nullable=True),
sa.PrimaryKeyConstraint('id')
)
# ### end Alembic commands ###
def downgrade():
# ### commands auto generated by Alembic - please adjust! ###
op.drop_table('some_table')
# ### end Alembic commands ### What I see on the database is the creation of a new type
If I downgrade this migration, the table is correctly dropped, but not the type. This make impossible to upgrading back to head, since the upgrading operation will try to create again the |
As mentioned in the downgrade comment, you can adjust the downgrade function. |
Thanks guys for your answers. I'll do as you suggest. |
this will not be worked on for the next release. |
enum is a long term issue that requires a full end-to-end approach be devised as there are many complications to the problem, including different database backends, SQLAlchemy's awkward constraints that it generates, and the fact that PostgreSQL wont let you change the elements of an ENUM inside of a transaction. if we make any API decisions or behaviors that conflict with a broader plan to support enum migrations in all forms, it would be much worse. this bug is already an example of early assumptions that don't hold up in practice (SQLAlchemy creates the "enum" for you automatically, but then alembic's "drop table" command doesn't know about the columns). im hoping after SQLAlchemy 2.0 is out and all tools are on python 3 i might have time to start thinking about an all new approach to the whole issue. |
Another thing to consider on PostgreSQL is that emun are append only, you cannot remove values from them |
I understand this is a difficult problem to solve but it would be a useful feature. there are many ways to update/drop enums in Postgres outlined here https://blog.yo1.dog/updating-enum-values-in-postgresql-the-safe-and-easy-way/ |
<!-- Thanks for your contribution! As part of our Community Growers initiative 🌱, we're donating Justdiggit bunds in your name to reforest sub-Saharan Africa. To claim your Community Growers certificate, please contact David Berenstein in our Slack community or fill in this form https://tally.so/r/n9XrxK once your PR has been merged. --> # Description The last alembic migration definitions fail when using PostgreSQL as the database. This PR fixes this by allowing upgrade and downgrade properly. For more info about the problem, see here sqlalchemy/alembic#886 **Type of change** (Please delete options that are not relevant. Remember to title the PR according to the type of change) - [X] Bug fix (non-breaking change which fixes an issue) **How Has This Been Tested** Changes have been tested using a local database to apply migrations (update and downgrade) **Checklist** - [ ] I added relevant documentation - [ ] follows the style guidelines of this project - [ ] I did a self-review of my code - [ ] I made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] I filled out [the contributor form](https://tally.so/r/n9XrxK) (see text above) - [ ] I have added relevant notes to the CHANGELOG.md file (See https://keepachangelog.com/) --------- Co-authored-by: Francisco Aranda <[email protected]>
…ove command workaround for sqlalchemy/alembic#886
…ove command workaround for sqlalchemy/alembic#886
I assume |
sure, you can run any supported sql command by using |
Given a model definition with an Enum, the resulting autogenerated migration creates a type in the database (Postgresql).
The relative downgrade migration doesn't drop it from the database, making it impossible to perform an upgrade (since this type is already existing).
The text was updated successfully, but these errors were encountered: