1: да, можно обойтись одной промежуточной таблицей вместо создания промежуточной таблицы для каждой сущности, которая будет иметь отношение к проекту
2: при удалении проекта каскадно удалятся все записи из attachments, в миграции указан внешний ключ с модификатором поведения при удалении. Однако, при удалении пользователя или команды ничего не произойдёт, так как метод morphs() создаёт поля и добавляет индекс, но не ставит ограничения и связи по внешним ключам. Для исправления этого можно воспользоваться хуками жизненного цикла моделей или сделать что-то ещё, что будет имитировать поведение внешних ключей. Согласен, что внешние ключи надёжнее.
3: про ядро согласен
Про использование трейтов для выноса общих методов полиморфных связей. Тут у модели команды и у модели человека будут одинаковые методы для связи к проекту, чтобы их не дублировать — вынес в трейт
А в системе обязательно должен находиться список этих статусов?
Если они не так важны, то можно удалять их перед запуском каждого теста с помощью запроса внутри функции setUp().
Ещё есть удобные трейты — DatabaseTransactions и RefreshDatabase. Первый открывает транзакцию и не закрывает её, поэтому состояние базы не изменяется, а второй — делает artisan migrate:refresh перед каждым тестом и откатывает-накатывает состояние БД, но это не всегда применимо.
Очень расстраивают компании, которые ища джунов, дают им 12 часов на реализацию решения задачи на самостоятельно написано фреймворке
Джун — понятное растяжимое, но не настолько ИМХО
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
интересная статья, спасибо!
от себя добавлю, что Арсений является прекрасным человеком и специалистом, очень советую его хантить!
Благодарю за вопросы
2: при удалении проекта каскадно удалятся все записи из attachments, в миграции указан внешний ключ с модификатором поведения при удалении. Однако, при удалении пользователя или команды ничего не произойдёт, так как метод morphs() создаёт поля и добавляет индекс, но не ставит ограничения и связи по внешним ключам. Для исправления этого можно воспользоваться хуками жизненного цикла моделей или сделать что-то ещё, что будет имитировать поведение внешних ключей. Согласен, что внешние ключи надёжнее.
3: про ядро согласен
Если они не так важны, то можно удалять их перед запуском каждого теста с помощью запроса внутри функции setUp().
Ещё есть удобные трейты — DatabaseTransactions и RefreshDatabase. Первый открывает транзакцию и не закрывает её, поэтому состояние базы не изменяется, а второй — делает artisan migrate:refresh перед каждым тестом и откатывает-накатывает состояние БД, но это не всегда применимо.
Очень расстраивают компании, которые ища джунов, дают им 12 часов на реализацию решения задачи на самостоятельно написано фреймворке
Джун — понятное растяжимое, но не настолько ИМХО