Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Здравствуйте.
Отредактировал файл миграции. Подскажите, как теперь выполнить обновление структуры бд без потери данных, если такое возможно. Пробовал делать php artisan migrate:refresh, но пропадают данные.
Не в сети
На этапе разработки лучше всего "сидить" (не уверен как на русский лучше перевести, в английской документации это seed) данные и пользоваться migrate:refresh. Таким образом, данные полностью удаляются и все таблицы создаются заново, потом "сидятся" данные.
Данные обычно создаются с помощью model factories и пакета faker. Можно использовать и реальные данные.
Другой подход - это создать новую миграцию для изменения только одного столбца, например. Но при таком подходе в крупном проекте можно закончить с полутысячей миграций и поддержка проекта будет адом. Я бы использовать этот подход только тогда, когда разработка завершена и сайт уже работает.
Не в сети
Не в сети
}%> потом "сидятся" данные.
"Загружаются начальные данные", не?
Когда говоришь seed в контексте данных, как-то сразу понятно о чем речь. Если я скажу "загружаются начальные данные", то совсем непонятно о чем речь. "Сеять" тоже как-то не очень. ) Может есть еще варианты?
Не в сети
- Когда говоришь seed в контексте данных, как-то сразу понятно о чем речь. Если я скажу «загружаются начальные данные», то совсем непонятно о чем речь.
Это понятно только потому, что ты уже имеешь об этом представление. Представь, что ничего не знаешь о торрентах и тебе говорят — «посидируй», «раздай». Кого «посадить», чего «раздать»? Как вообще биты можно «сажать»?
Здесь тоже самое. Везде говорится «seed» и глаз привык, хотя конкретно в данном случае перевод, на мой взгляд, более понятен, чем оригинальный термин — seed используется совершенно в разных контекстах, от торрентов до инициализации ГПСЧ. «Загрузка начальных данных» более конкретна.
Не в сети
Не в сети
Спасибо. Буду разбираться с этой загрузкой начальных данных.
Изменено Olrand (29.12.2016 10:31:18)
Не в сети
Proger_XP пишет:}%> потом "сидятся" данные.
"Загружаются начальные данные", не?Когда говоришь seed в контексте данных, как-то сразу понятно о чем речь. Если я скажу "загружаются начальные данные", то совсем непонятно о чем речь. "Сеять" тоже как-то не очень. ) Может есть еще варианты?
seed: варианты перевода
имя существительное
семя - seed, semen, seminal fluid
семена - seed
зерно - corn, grain, seed, kernel, granule, berry
потомство - progeny, seed, posterity, breed, issue, generation
источник - source, spring, origin, fountain, fount, seed
потомок - descendant, child, offspring, descendent, scion, seed
начало - start, starting, beginning, outbreak, origin, seed
сперма - sperm, semen, cum, jizz, spunk, seed
глагол
сеять - sow, seed, disseminate, inseminate, garble, seminate
засевать - sow, seed, inoculate, crop
семениться - seed
идти в семя - seed
ронять семена - seed
очищать от зернышек - seed
отбирать игроков - seed
Иногда Английский язык очень скудный, в сравнении с Русским, а иногда прям брызжит контекстом.
Не в сети
Почитайте про миграции в доках. Там же есть как вносить изменения в таблицу добавляя, удаляя столбцы и более ничего не трогая.
Добавление столбца в таблицу:
Schema::table('users', function ($table) {
$table->string('email');
});
Не в сети
Почитайте про миграции в доках. Там же есть как вносить изменения в таблицу добавляя, удаляя столбцы и более ничего не трогая.
Я выше написал о недостатке этого метода.
Не в сети
Grumm пишет:Почитайте про миграции в доках. Там же есть как вносить изменения в таблицу добавляя, удаляя столбцы и более ничего не трогая.
Я выше написал о недостатке этого метода.
Если всё делать правильно, то и жить не за чем, ибо жизнь без ошибок (однако я лично этот подход не считаю ни ошибкой ни "плохим" решением) скучна и однообразна.
Собственно по "недостаткам этого метода"...
На мой взгляд перед релизом всегда одлжен быть период причёсывания кода и пакетов. Если программист, ответственный за миграции перед публиацией Проекта соберёт все 100500 миграций одной таблицы в один файл, то честь ему и хвала. А если нет, так что спорить, - с него всё равно рано или поздно спросят "WTF?".
На мой взгляд стоило всего лишь поделиться вариантами решения его вопроса, обсасывать идеологию программирования тут было без какого-либо смысла.
Не в сети
Если всё делать правильно, то и жить не за чем, ибо жизнь без ошибок (однако я лично этот подход не считаю ни ошибкой ни "плохим" решением) скучна и однообразна.
Твой совет - делать все через жопу, чтобы жить веселее было?
На мой взгляд перед релизом всегда одлжен быть период причёсывания кода и пакетов. Если программист, ответственный за миграции перед публиацией Проекта соберёт все 100500 миграций одной таблицы в один файл, то честь ему и хвала. А если нет, так что спорить, - с него всё равно рано или поздно спросят "WTF?".
На мой взгляд стоило всего лишь поделиться вариантами решения его вопроса, обсасывать идеологию программирования тут было без какого-либо смысла.
Я поделился с человеком опытом и хорошей практикой. Лепить франкенштейна и потом причесывать - это не хорошая практика, если можно заранее делать по уму.
Не в сети
- Если программист, ответственный за миграции перед публиацией Проекта соберёт все 100500 миграций одной таблицы в один файл, то честь ему и хвала.
Согласен с Алексеем, такой подход противоречит идее миграций, которая в том, чтобы единожды созданная миграция не менялась, уж тем более не объединялась. Есть у тебя 10 человек в команде, каждый создает свои миграции в отдельных файлах. Дальше каждый накатывает/откатывает их как угодно локально. Добавилась новая в конец очереди — не проблема.
А если кто-то решает миграции «почистить», то аналогичную процедуру в точности должен выполнить каждый член команды. Естественно, кто-то накосячит. От чего, в общем-то, миграции и призваны защищать.
Не в сети
Страницы 1