jazzus, ну как нет. https://laravel.com/docs/8.x/seeding - нужно использовать исключительно для:
-автоматизация тестирования в целом
-сидирования базы данных на машине разработчиков чтобы легче и быстрее строить/дебажить приложения.
ВСЁ. Дальше, будут только костыли, проверка чтобы кто-то не то запустил и тп.
И даже если вы пройдётесь по топу гитхаба(согласен что не показатель, но) вы там в сидерах не увидите ничего, кроме непосредственно сидирования базы данных только для нужд тестирования и разработки.
А вот использования миграций для разных целей, попадается постоянно, тк это намного безопаснее и прямо подразумевает открытым способом изменения в БД(изначально задумывалось только схемы, но..)
Просто даже банальный пример, у чего то в БД нужно поменять допустим префикс, я конечно сделаю миграцию и пройдусь по всем значеним(ну после изменения логики работы уже внутри приложения.)
Вот примеры от других разработчиков:
BookStack - приложение для организации документации и около того, установки и создание ролей поумолчнию.
Spatie - одни из крупных популязаторов и разработчиков пакетов для Ларавел, у них множество примеров, вот на их оф сайте например есть такая миграция да и другие там есть, и в целом они миграции в этом ключе используют.
Laravel-Backpack у себя ив демо и в других штуках бывает
Ну короче. Снова таки, я не говорю что это прям хороший патерн и тд и тп, но довольно часто он таки не антипатерн. позволяет в некотором роде использовать и автоматизацию и гит для контроля БД и тп.
В основном конечно встречается не обычных библиотеках, цмсках и тп, а в продуктовых решениях, где есть кейсы допустим хранения поддерживаемых языков и бывает что-то меняется(ну ввели вначале что просто ru, en и тп, а потом поняли что нужно ru_RU, en_US и тп ) и бывает такую логику удобнее всего писать именно в миграциях из-за прозрачности работы.
А использования db:seed портит многое, нарушает и принципы для чего создан механизм(блин да там даже по набору инструментов видно что это для тестирования и или локальной разработки), легче совершить фатальную ошибку с рефрешем всего, те нужна доп слежка, доп ключи для обхода защиты на продакшене и тп и тд. Да и тупо в сидерах будут лежать не те классы что ожидаешь. Ну камон.
jazzus, ну допустим разный опыт, разные проекты и тп.
А насчёт миграций советую пересмотреть ваше отношения. Очень удобный инструмент, удобно что потом он и в гит и тп отправляется. Всё работает прозрачно в плане populate my database. Или изменений чего либо.
Миграций вовсе не только для создания и изменения таблиц.
И я могу спокойно знать что моё приложение развернется так, как я хочу. Либо обновится у клиента так как я хочу и тп.
В общем кейс и использование распространенное, не всегда лучший вариант, иногда вредный, нередко полезный и удобный. Каждый раз принимаются решения в зависимости от ситуации.
Вот db:seed для случаев отличных от разработки и тестирования - зло однозначно
FanatPHP, пример же условный, всё оттачивается уже на конкретных сценариях и тп. Потом даются реокмендации и тп. Более того, саму генерацию картинок можно и делать отложено после загрузки, зная популярные форматы что будут использоваться..
Ну короче, дальше уже дело касается конкретных сценариев работы.
jazzus, ну вот, вы сами аппелируете к документации, где прямо и написано что сидирование(seeding) в ларавел - для тестов. Это даже видно из логикии работы механизма, различных фейкров и автоочищения и запрета на продашене запускать.
Насчёт миграций, то так делают люди в реальных проектах.
Это нормально, удобно и прозрачно.
Повторюсь, не для всех кейсов.
Но:
-позволяет легко и прозрачно откатится, как и с обычными миграциями
-позволяет дальше регулировать и менять данные(или это тоже не в миграциях делать?)
Ну к примеру, храню я роли и название ролей по умолчанию не в хелпер классе статитикой, а в базе данных.
Вот создал миграцию, упростим, айди роли, название роли, права.
Следующей миграцией я ее заполнил: Админ, Модератор, Юзер.
Пользуемся всё ок.
Потом решили что лучше пусть Юзер будет Пользователь называться
делаю новую миграцию, переименовал.
Чем это лучше чем в админке? А тем что у меня остается чёткость, история изменения и если я разворачиваю свое приложение где-то ещё(не важно продаю лия короболчное решение, или новый сервак, но с нулевой установкой и тп и тд), то всё будет как нужно.
Да полной кейсов когда это удобно.
Отдельно отмечу, что по хорошему часто могут нужны отдельные сервисы, алгоритмы и тп, возможно более сложные, встроеные в общую систему деплоя и развёртывания. Тогда миграции идут лесом, это отдельные классы и функционал для этой цели.
Ваш же совет юзать сидеры для этого через db:seed просто вредный, и потом, при росте приложения или расширения тестирования приведет к проблемам. Я уже молчу что там выстрелить себе в ногу ГОРАЗДО легче при развёртывании приложения. Тут даже спорить не о чем.
Повторюсь, если вам удобны эти фейкеры и прочие сид штучки, так их можно спокойно использовать в любом вам нужном месте приложения, своих сервисах и в тч миграциях, если вам нужно.
НО! Конечно же я бы тоже не советовал его использовать, сам навозился в свое время. Хотя, мне иногда говорят что в последние годы ситуация получше. А мне вот слабо верится, тк им то и не нужно делать лучше, их часто "советуют" или впаривают безальтернативно. А если продажи итак будут, зачем парится...
jazzus, а и кстати да, если вам нужен просто тот функционал, то конечно же в миграциях вполне можно использовать сид классы, когда это нужно.
Ну и отдельно отмечу. Можно, можно и в сидах делать эту логику, добавлять различные доп проверки и условия и логику, чтобы отслеживать что сейчас продашн и тп.. но это уже костыли и обход прямого предназначения автоматизации всего движа с artisan db:seed и тп. Этот инструмент не для этого затачивался
jazzus, занимаюсь. Вы просто слишком остро спорите. Скажу ещё раз, в целом насчёт миграций я согласен, просто отметил что их можно использовать и для наполнения БД начальными значениями, умолчаниями и тп.
Те сиды с ларавел(отмечаю ссылкой только чтобы сказать что мы говорим об одном и тоже) нее предназначены для этой цели, более того это вредит в дальнейшем, так как потом будет мешать и тестированию и тп. Прошу заметить что на проде по умолчанию даже нельзя их запустить. И я как раз это всё говорю и в рамках развития проекта дальше. Противоречий в этом нет. Те штуки о которых вы говорите делать в админке это отдельная история и другие кейсы. Здесь же ситуация как раз таки и развити проекта(в процессе разработки) и развертывания проекта. И очень много случаев когда удобно и заполнять и корректировать данные в таблицах именно в отдельной специально для этого нужной миграции.
И кстати в миграциях тоже все делается просто, без лишнего кода и, главное , остается та же поддержка отмены шагов и тп.
Повторю ещё раз: ваш супер вредный совет использовать это: https://laravel.com/docs/8.x/seeding для чего-то помимо штук касаемых тестирования приложения вредны. В миграциях в некоторых случаях можно и вполне ок, а часто нужно писать отдельную нормальную логику. В админках и тп это вообще отдельная тема.
jazzus, пф. Меняешь следующей миграцией.
Снова таки, я не говорю что это единственный и истинно праивльный путь. Я говорю что:
Эти сидеры - точно нет, разве что у вас просто проект вот прям на раз, быстренько набросали, запустили и забыли. А так нет.
В определенных сценариях устанавливать данные через миграцию вполне себе ок, так же пишешь логику и установки и откатки изменений. А потом если нужно можно и менять в дальнейшем следующими миграциями по необходимости. Снова таки, безусловно это на айс, но рабочее решении при многих ситуациях.
А так конечно же отдельная логика разворачивания приложения, где один из этапов пишешь свою, да даже через потом и в тот же артизан для удобства добавляешь команду php artisan dbpopulate, которая и будет делать всё что нужно.
А так... сильных ужасных подводных камней в заполнении некоторых данных в миграции специальной нет, выстрелить себе в ногу конечно можно, но в целом, при многих простых сценариях, допустимо.
jazzus, ну конечно. Поэтому я и написал зависит от ситуации. Тут тогда в целом и сами миграции не всегда удобны. Но конкретно инструмент сидов встроенные в ларавел таки предназначен и логически и по устройству и по работе в логие приложения ларавела для сидов тестовой базы в рамках различных видов тестирования приложения. Поэтому сами изначальные данные, вполне ок, при многих сценариях, заливать и в миграциях, тем более там можно соблюдать достаточную гибкость и абстракцию по необходимости.
Ну а так, в более сложных кейсах, это уже конечно же отдельная тема и рассматривается индивидуально.
intriga93, ну да. Это на самом деле условно приняли за 2. На самом деле разница может быть и больше. но 2x уже решает. Вы почитайте о проблеме. Суть в том что на экранах высокого разрешения, в одном обычном "пикселе" на "ретина" дисплеях их больше. ОС масштабирует все интерфейсы, в тч и браузере это делает. А обычные(растровые) картинки при этом масштабируются вверх, и выходит "мыло"(на модном айфончике например), и это особенно все контрастирует в сравнении с суперчеткими шрифтами интерфейсами вокруг. Отсюда популярность и любовь всех и вся к векторной графике везде где можно. С фотками мы тут никуда не денемся, поэтому сегодня при использовании фото принято делать умную "порезку" с учетом и несколько разрешений экранов. В верстке в один тег записывается весь набор изображений, которые уже по условию и показываются пользователю. Это я грубо говоря всё описал.
Не совсем для этого. Нужно смотреть конкретный сценарий. Сида в целом существуют для тестирования приложения и если это скорее часть развёртывания и загрузка начальных данных, то делать нужно миграции.
SM_ST, они тоже по умолчанию не выводятся в отдельные css, инлайн изначально. А вот exctractCSS - как раз для того чтобы их вытаскивать в отдельные файлы. В базовых настройках стоит exctractCSS в false
SM_ST, так отключи extractCSS или поставь в false(так по умолчанию)
Плюс в секции css nuxt config засунь глобалки что используешь(у меня вот на одном проекте):
https://laravel.com/docs/8.x/seeding - нужно использовать исключительно для:
-автоматизация тестирования в целом
-сидирования базы данных на машине разработчиков чтобы легче и быстрее строить/дебажить приложения.
ВСЁ. Дальше, будут только костыли, проверка чтобы кто-то не то запустил и тп.
И даже если вы пройдётесь по топу гитхаба(согласен что не показатель, но) вы там в сидерах не увидите ничего, кроме непосредственно сидирования базы данных только для нужд тестирования и разработки.
А вот использования миграций для разных целей, попадается постоянно, тк это намного безопаснее и прямо подразумевает открытым способом изменения в БД(изначально задумывалось только схемы, но..)
Просто даже банальный пример, у чего то в БД нужно поменять допустим префикс, я конечно сделаю миграцию и пройдусь по всем значеним(ну после изменения логики работы уже внутри приложения.)
Вот примеры от других разработчиков:
BookStack - приложение для организации документации и около того, установки и создание ролей поумолчнию.
Spatie - одни из крупных популязаторов и разработчиков пакетов для Ларавел, у них множество примеров, вот на их оф сайте например есть такая миграция да и другие там есть, и в целом они миграции в этом ключе используют.
Laravel-Backpack у себя ив демо и в других штуках бывает
Ну короче. Снова таки, я не говорю что это прям хороший патерн и тд и тп, но довольно часто он таки не антипатерн. позволяет в некотором роде использовать и автоматизацию и гит для контроля БД и тп.
В основном конечно встречается не обычных библиотеках, цмсках и тп, а в продуктовых решениях, где есть кейсы допустим хранения поддерживаемых языков и бывает что-то меняется(ну ввели вначале что просто ru, en и тп, а потом поняли что нужно ru_RU, en_US и тп ) и бывает такую логику удобнее всего писать именно в миграциях из-за прозрачности работы.
А использования db:seed портит многое, нарушает и принципы для чего создан механизм(блин да там даже по набору инструментов видно что это для тестирования и или локальной разработки), легче совершить фатальную ошибку с рефрешем всего, те нужна доп слежка, доп ключи для обхода защиты на продакшене и тп и тд. Да и тупо в сидерах будут лежать не те классы что ожидаешь. Ну камон.