Кстати, ещё такой вопросик, почему две сущности в одной миграции?

Не знаю, норм это или нет

а сколько должно быть?

2

а сколько есть?

1

Ты попросил сгенерировать одну, столько и получил

В миграции две сущности

Ты попросил сгенерировать одну миграцию, столько и получил

make:migration

Ack Pong

?

.

а это точно проблема?

Не) просто интересуюсь

ок, давай с другой стороны зайдём. что будет плохого, если одной миграцией накатится две таблицы?

Тут пока норм, а если будет 300 сущностей 🌚

В чем тут проблема?

300 строк, вместо 300 файлов ))

Не смог не отреагировать на это) можно конечно весь код в одном файле писать

И будет у нас один файлик но с Лямом строк кода

ну все верно, одна строка - один файл

иногда лучше не реагировать

Это если бы миграция состояла из одной строки)

Понимаю) но у меня не когда это не выходит 😊

Создаёшь одну-две-три-пять сущностей. Генерируешь миграцию. Коммитишь все это. Выполняешь миграцию. Если все работает - супер. Если миграция упала - она откатиться, откатываешь проект на предыдущий коммит. И у тебя и в этом случае все работает. Если будешь дробить миграции - есть риски попасть в какой-то промежуточный стейт, когда код ещё не работает, а база уже поменялась, но не полностью

О кстати, вот в чем ещё проблема. Например: есть таблицы users, subscriptions Миграция одна, мы тестируем Subscriptions, если тут что-то не так, то все пользователи удалятся при откате, а значит, придётся снова регистрироваться

тест на проде?

Dev

причем здесь тогда "придётся снова регистрироваться"

Потому что subscriptions работает только, если юзер авторизированный

так "все пользователи удалятся при откате"

Ну да, если мы откатим миграцию, то наш пользователь удалиться

ну логично, что "придётся снова регистрироваться" фикстуры мы не знаем

У тебя проблема не в табличках, а в коде. У тебя не работает связка юзер+подписка. Откати все вместе, исправь и вылей

Забыл про фикстуры 🌚