@LamaLove но битрикс я так и не понял) сколько с ним не пересекался)

а что конкретно в фениксе лишнее для этой функциональности? даже генераторов куча, хоть вообще код не пиши да генерируй

я феникс не пробовал так глазом пробегал, генераторы - круды?

я короче на работе сижу програю и когда компилирую и выгружаю проект, то читаю про эликсир, феникс, лай вью

немного сложно потому что я один сижу, сам себе ставлю задачи и сам их решаю))) такой вот сам себе программист)

и круды и бд и еще по мелочам

да. По просту говоря:
- добавить validate_inclusion, которая будет валидировать статусы
- добавить кастомную валидацию aka validate_status_transition, которая будет проверять переход от одного статуса к другому

Понял. Да подходит такой вариант.  Enum я поставил структуру, но статус добавится или имя изменится и произойдет - боль. Поэтому сделаю на changeset пожалуй.

я бы рекомендовал enum делать на уровне базы, добавление не сильно сложное

а вот всякие переименования, да чуть больно, но не рокетсайнс

просто потому что если хочеться статусов то рано или поздно понадобяться чеки разные, когда другие поля зависят от статуса - и это все проще на уровне бд делать, напихал проверок в constraint и спи спокойно

А потом ушёл, пришёл кто-то другой и спать перестал в поисках этих проверок...

это звучит как "пришел кто-то не знающий о возможности реализации констрейнтов в базе". плохо звучит.

А в чем проблема не делать Enum в базе а делать его на уровне Changeset ?

Констрейнты - это штука заводная, но если вы хотите шардирование, горизонтальный скейлинг вы все-равно будете отказываться и от нормализации и от некоторых других вещей в угоду скорости

Я решил не делать enum так как это какая-то боль прибитая гвоздями получается. Но наверняка применима в каких-то случаях (когда, что-то надо прибить гвоздями).

кто в курсе, можно переопределить както функционал  Exception
чтоб при логировании дополнительно фильтровать output?

Exception.normalize/3

enum на уровне БД может оправдать себя только в том случае, если в эту БД будут писать данные несколько приложений/апи/админы напрямую sql-запросами. Если приложение у вас одно и в БД гарантированно никто никогда не полезет, то хватит проверки на уровне changeset. Добавить ограничение на уровне БД никогда не поздно, но если сделать это слишком рано, то будете кучу миграций писать на каждую попытку добавить/удалить значение. При том с удалением вообще все сложно, т.к. нужно будет создавать новый констрейнт и через дополнительную колонку копировать данные.

enum вместо string даёт экономию дискового места при сохранении читабельности
enum вместо int экономии можно считать что не даёт, но и читабельность не сохраняет
Напомните, экто использует словари enum <-> int или строками херачит?

естественно, эта экономия сказывается на больших объёмах.
и как бы с одной стороны стартапу не обязательно об этом париться,
а с другой стороны когда объём данных вырастает - обычно задач становится столько что до конвертации string -> enum руки не доходят, и мысль одна на всех "что ж сразу-то не сделали"