Комментарии 7
При всей кажущейся привлекательности использование ENUM в конечном итоге оказывается скорее вредным, чем полезным. Требуется контроль изменений в базе и в коде, дополнительные проверки в базе, сложности при расширении ENUM и т.д.
Проще использовать int или char(4) например, если нужно большей человекочитаемости.
Источник изменений будет только один - код, ведь по сути элементы ENUM - константы и базе все равно, что там. Вся история с миграциями тоже уходит.
Ну и в некоторых случаях очень удобно использовать uint + битовые маски для хранения флагов вместо ENUM.
Возникла проблема, так как мне требовалась фильтрация по тексту, и необходимо было чтобы в базу данных попадали атрибуты value, а не name.
Для этого же есть параметр values_callable у Enum
status = Column(
PgEnum(
OrderStatusEnum,
name="order_status_enum",
create_type=False,
values_callable=lambda e: [field.value for field in e],
),
nullable=False,
default=OrderStatusEnum.WAITING_FOR_WORKER,
)
Я немного ранее тоже с Enum в SQLAlchemy игрался, но пошёл по пути уникальных целочисленных Enum
Спасибо за статью.
Сам столкнулся к этой проблемой.
Использование PostgreSQL Enum в SQLAlchemy. И проблемы с ним