5 ms·
Heyya! Close customer here. > When False, uses VARCHAR + check constraint for all backends Is this behaviour new? Or is it that alembic still doesn't pick up
by aidos 3y ago
Heyya! Close customer here.
> When False, uses VARCHAR + check constraint for all backends
Is this behaviour new? Or is it that alembic still doesn't pick up changes to the enum to recreate the constraint? We implemented our own alembic hooks to automate the migrations for us. We've found the check constraint model to be fairly effective.
- wojcikstefan 3y agoHiya Aidan! :D > Is this behaviour new? Don't think so. Even the docs for SQLA v1.3 ([0]) mention it: > native_enum – Use the database’s native ENUM type when available. Defaults to True. When False, uses VARCHAR + check constraint for all backends. The VARCHAR length can be controlled with Enum.length [0]: https://docs.sqlalchemy.org/en/13/core/type_basics.html#sqlalchemy.types.Enum.params.native_enum https://docs.sqlalchemy.org/en/13/core/type_basics.html#sqla... -- > Or is it that alembic still doesn't pick up changes to the enum to recreate the constraint? Off the top of my head, I believe Alembic doesn't pick it up automatically. We make a lot of manual tweaks to our auto-generated Alembic migrations and I believe adding / modifying the CHECK constrains is part of it.
- aidos 3y agoHappy to ping you guys over the code if you want to look. It’s probably fairly tweak-able to handle your specific cases.