изменения полей - отдельная миграция.
Ну, соответственно, я ему задал вопрос. Вот выкатился он, развернул всё. Работает, педалит, данные добавляются. Тут ему надо добавить ещё одну связь. Что он будет делать? Идти и перенакатывать отредактиваронные миграции с новыми полями?
1. Твои старые миграции можно дампнуть в один файл, который тоже будет выполняться. 2. Вон, у Хелдара под 300 миграций (не помню точно). Нормально живёт.
Маловато
475 элементов
Каша в голове получиться у того, кто будет твой код разгребать
так потом применишь: https://laravel.com/docs/8.x/migrations#squashing-migrations и будет одна
И что с того? Ты там всё время сидишь? Ну да, давай будем херить данные, зато файлики красиво будут показываться.
так..надо доку почитать :)
Миграции не для этого. Понимаю, прикольно иметь там читаемый дамп БД, но у миграций другая функция. Миграции - это git для структуры базы данных. Ты же не коммитишь так, чтобы в одном коммите была папка Http, в другом - Models и т.п. ? Вот и с миграциями так же. Там неизбежно будет хаос, смирись с этим. Цель миграций - описать в тексте структуру БД, чтобы ты в любой момент мог спуллить проект на другом компе и развернуть там БД в рабочем виде. А потом спуллить ещё раз через месяц и накатить изменения поверх существующей БД, подтянув её структуру до актуальной. Править структуру БД в pma, а потом вносить данные в миграции - это значит отказываться от функционала миграций. Отучайся так делать, это путь в никуда. Когда будешь работать над проектом не один, а в команде - эта привычка моментально оторвёт тебе обе ноги.
Обсуждают сегодня