Согласен. Тоже рабочий вкариант. Но это уже зависит от политики разработки.

Да, ошибка моя была в том что я просто скопировал 2 строки кода из stackoverflow
и у меня переобразовало в строку
А сейчас уже понял что json_encode был лишним )

Слышал о таком, что в некоторых командах используемые версии задает тимлид и только он их обновляет.

Предполагаю, что в больших командах это лучшее решение, как минимум потому что:

1. Проще выяснить причину возникающей ошибки с каким-либо пакетом;
2. Исключается ошибка "битья локтями" при PR.

Ну это только если ты не сам тимлид)

Сейчас я тимлид, но у нас проекты поделены между несколькими сотрудниками так, что вдвоем над одним не работаем, если только кому-то не потребуется моя помощь.

Салют всем. Немного не по теме, но не знает ли кто, можно ли в яндекс деньгах делать переводы по токену или еще как? Например нужно отправить автоматический перевод n-й суммы раз в месяц.  Списание за лицензию, если проще. Ясное дело это нужно прикрутить к ларавел. Какие варианты вообще есть ? Что бы автоплатеж, без всяких кодов подтверждения и тд

Есть сущность Review (отзыв), он проходит через несколько стадий обработки: оператор не назначен, в работе, закрыт, закрыт с опозданием, проигнорирован. По сути каждый статус соответствует определённому состоянию модели, например: закрыт с опозданием - это когда во первых processing_user_id не null, дата в closed_at позже чем expires_at. проигнорирован, это когда опять же назначен пользователь, но при этом текущее время > чем considered_ignored_at и так далее.
Как лучше работать со статусами? Я вижу 2 варианта: 1. Создать в БД поле status, и в коде явно записывать в него необходимый статус (пусть то enum или int). 2. Создать виртуальное поле в модели ( getStatusAttribute() ), и возвращать тот или иной статус, в зависимости от текущего состояния модели (описал пример выше).

Не могу принять решение, нет опыта в подобном вопросе. Что с большей вероятностью в дальнейшем выстрелит в ногу?

Ружьё 😊
Не благодари)

мда

Как часто статусы будут меняться и какое их количество? Если 1-10 статусов никогда не меняющихся, то лучше их в конфиг засунуть и оттуда дергать.
Если статусы кто-то может редактировать, то лучше держать их в базе в своей таблице, а другие записи релейшеном к ней цепляться должны.

я нередактируемые статусы загоняю в enum и прописываю константами в моделях. На уровне БД - перестрахован, на уровне моделек - Вызов всегда будет без ошибок в любой точке программы, например Invoice::STATUS_WAIT

Статусов ограниченное кол-во, меняться не будут, да и вопрос не в том где хранить, а в том как с ними работать?

Про выстрел в ногу:

1. Выстрелит когда нужно будет изменить заголовок, добавить или удалить статусы.
2. Выстрелит лишней таблицей в БД и, следовательно, лишним запросом.
3. Если в getStatusAttribute пихать, то смотри пункт 1, а в get..attribute выводи результат.

Сунь в бд и не парься. Меньше вероятности выстрелить в ногу

Не согласен

Зачем лишняя таблшица в бд?

интом хранишь

а в модели массив с тайтлами

[
1 => 'Active',
2 => 'Processed'
]

в статик свойстве ну или в константах