Есть небольшой тестовый проект(интернет-магазин). Довольно часто делаю refresh своих миграций. Проблема в том, что при публикации товаров нужно выбрать город, для этого я лезу в pgadmin и вставляю туда свой дамп. Можно ли это делокак нибудь автоматизировать с помощью сидов? Что бы не фейковые города были, а реальные?
Не совсем для этого. Нужно смотреть конкретный сценарий. Сида в целом существуют для тестирования приложения и если это скорее часть развёртывания и загрузка начальных данных, то делать нужно миграции.
Александр Талалаев, сидить через миграции плохая идея по множеству причин. Например если разные приложения с одной структурой бд но разным набором данных, проблема обновления данных, периодическое добавление данных, добавление данных после развертывания и тд. И вообще миграции не про развертывание, а про точную и безгеморную актуализацию структуры бд на разных приложениях (например локал и продакшн).
jazzus, ну конечно. Поэтому я и написал зависит от ситуации. Тут тогда в целом и сами миграции не всегда удобны. Но конкретно инструмент сидов встроенные в ларавел таки предназначен и логически и по устройству и по работе в логие приложения ларавела для сидов тестовой базы в рамках различных видов тестирования приложения. Поэтому сами изначальные данные, вполне ок, при многих сценариях, заливать и в миграциях, тем более там можно соблюдать достаточную гибкость и абстракцию по необходимости.
Ну а так, в более сложных кейсах, это уже конечно же отдельная тема и рассматривается индивидуально.
Тут тогда в целом и сами миграции не всегда удобны
здесь они как раз необходимы. Если я добавляю поле то мне нужно гарантированно получить его в другом приложении/ в тестовой бд / у другого разработчика и тд. Я вообще не знаю причин не использовать миграции.
для сидов тестовой базы
Идеологически да) На практике сами сиды к тестированию отношения не имют. Фабрики - да. Но сиды сидят в таблицу что напишешь.
при многих сценариях, заливать и в миграциях
Здесь только один сценарий технически возможен - если ты 100% никогда эти данные не будешь менять. В другом случае придется вытаскивать код добавления из миграций в что-то новое. Скорее всего в сиды) И тогда проще сразу создать нужный сид. Но даже если данные не будут меняться все равно непонятно зачем лишать себя возможности делать миграции и не сидить данные. И в Ларавел таких кейсов нет.
jazzus, пф. Меняешь следующей миграцией.
Снова таки, я не говорю что это единственный и истинно праивльный путь. Я говорю что:
Эти сидеры - точно нет, разве что у вас просто проект вот прям на раз, быстренько набросали, запустили и забыли. А так нет.
В определенных сценариях устанавливать данные через миграцию вполне себе ок, так же пишешь логику и установки и откатки изменений. А потом если нужно можно и менять в дальнейшем следующими миграциями по необходимости. Снова таки, безусловно это на айс, но рабочее решении при многих ситуациях.
А так конечно же отдельная логика разворачивания приложения, где один из этапов пишешь свою, да даже через потом и в тот же артизан для удобства добавляешь команду php artisan dbpopulate, которая и будет делать всё что нужно.
А так... сильных ужасных подводных камней в заполнении некоторых данных в миграции специальной нет, выстрелить себе в ногу конечно можно, но в целом, при многих простых сценариях, допустимо.
Александр Талалаев, и в итоге эта миграция будет выполнять роль сида, только с дублированием кода и в куче классов, отвечающих за структуру бд вместо ОДНОГО класса, отвечающего за наполнение бд.
Сидинг миграциями - это как раз для нерабочих проектов. Т.к. практически всегда данные меняются/расширяются/делятся на приложения и тд.
Эти сидеры - точно нет
Да кто это сказал-то? В доке даже пишут как засидить на проде. В разделе миграций таких примеров не наблюдаю.
отдельная логика разворачивания приложения
Блин, да причем тут разворачивание приложения?) Я так понимаю что ты после разворачивания проектом не занимаешься) Но есть еще этап развития и поддержки. И еще раз - когда нужно актуализировать данные, скрипты развертывания с миграциями это самый плохой вариант. Можно свой класс написать обновления таблицы и я раньше так делал. Но потом все перенес в сиды т.к. запускать удобно одной командой без лишнего кода и гемороя.
jazzus, соглашусь
от себя: сидами рассматриваю начальное наполнение базы, далее оно должно происходить самостоятельно\через админку (в зависимости от проекта)
и так же считаю что данным вообще не место в миграциях
Владислав Лысков, если есть такой функционал в админке и обновлять не много, можно и руками. У меня просто админки скудные, большую часть операций по актуализации/добавлению я делаю с помощью Ларавелевских методов в сидах типа insertOrIgnore и тд. Можно конечно свои классы писать, но я не вижу смысла зачем, когда в ларавел уже все есть. Если есть опасность засидить не то, что нужно можно запускать нужныпе классы после проверки app is production. Но ошибиться и грохнуть бд можно и своими скриптами.
jazzus, занимаюсь. Вы просто слишком остро спорите. Скажу ещё раз, в целом насчёт миграций я согласен, просто отметил что их можно использовать и для наполнения БД начальными значениями, умолчаниями и тп.
Те сиды с ларавел(отмечаю ссылкой только чтобы сказать что мы говорим об одном и тоже) нее предназначены для этой цели, более того это вредит в дальнейшем, так как потом будет мешать и тестированию и тп. Прошу заметить что на проде по умолчанию даже нельзя их запустить. И я как раз это всё говорю и в рамках развития проекта дальше. Противоречий в этом нет. Те штуки о которых вы говорите делать в админке это отдельная история и другие кейсы. Здесь же ситуация как раз таки и развити проекта(в процессе разработки) и развертывания проекта. И очень много случаев когда удобно и заполнять и корректировать данные в таблицах именно в отдельной специально для этого нужной миграции.
И кстати в миграциях тоже все делается просто, без лишнего кода и, главное , остается та же поддержка отмены шагов и тп.
Повторю ещё раз: ваш супер вредный совет использовать это: https://laravel.com/docs/8.x/seeding для чего-то помимо штук касаемых тестирования приложения вредны. В миграциях в некоторых случаях можно и вполне ок, а часто нужно писать отдельную нормальную логику. В админках и тп это вообще отдельная тема.
jazzus, а и кстати да, если вам нужен просто тот функционал, то конечно же в миграциях вполне можно использовать сид классы, когда это нужно.
Ну и отдельно отмечу. Можно, можно и в сидах делать эту логику, добавлять различные доп проверки и условия и логику, чтобы отслеживать что сейчас продашн и тп.. но это уже костыли и обход прямого предназначения автоматизации всего движа с artisan db:seed и тп. Этот инструмент не для этого затачивался
Александр Талалаев, да нельзя в миграциях это использовать. Я написал почему
Например если разные приложения с одной структурой бд но разным набором данных, проблема обновления данных, периодическое добавление данных
Плюс непонятная архитектура, непонятно где код в куче миграций, в отличии от одного класса сидов. Плюс прямое ненужное дублирование функционала сидов, сервисом, который этим не должен заниматься. Где в доках хоть один пример в миграциях который бы не относился к стрктуре бд? Его нет и быть не может. Т.к. миграции для струткры бд, а не для сидинга. Актуализировать данные новыми миграциями вообще ужас. Если сиды не нравятся, то тогда только свои скрипты, хотя я и не вижу в этом смысла, когда в ЛАравел есть удобный функционал. Но никак не миграции.
jazzus, ну вот, вы сами аппелируете к документации, где прямо и написано что сидирование(seeding) в ларавел - для тестов. Это даже видно из логикии работы механизма, различных фейкров и автоочищения и запрета на продашене запускать.
Насчёт миграций, то так делают люди в реальных проектах.
Это нормально, удобно и прозрачно.
Повторюсь, не для всех кейсов.
Но:
-позволяет легко и прозрачно откатится, как и с обычными миграциями
-позволяет дальше регулировать и менять данные(или это тоже не в миграциях делать?)
Ну к примеру, храню я роли и название ролей по умолчанию не в хелпер классе статитикой, а в базе данных.
Вот создал миграцию, упростим, айди роли, название роли, права.
Следующей миграцией я ее заполнил: Админ, Модератор, Юзер.
Пользуемся всё ок.
Потом решили что лучше пусть Юзер будет Пользователь называться
делаю новую миграцию, переименовал.
Чем это лучше чем в админке? А тем что у меня остается чёткость, история изменения и если я разворачиваю свое приложение где-то ещё(не важно продаю лия короболчное решение, или новый сервак, но с нулевой установкой и тп и тд), то всё будет как нужно.
Да полной кейсов когда это удобно.
Отдельно отмечу, что по хорошему часто могут нужны отдельные сервисы, алгоритмы и тп, возможно более сложные, встроеные в общую систему деплоя и развёртывания. Тогда миграции идут лесом, это отдельные классы и функционал для этой цели.
Ваш же совет юзать сидеры для этого через db:seed просто вредный, и потом, при росте приложения или расширения тестирования приведет к проблемам. Я уже молчу что там выстрелить себе в ногу ГОРАЗДО легче при развёртывании приложения. Тут даже спорить не о чем.
Повторюсь, если вам удобны эти фейкеры и прочие сид штучки, так их можно спокойно использовать в любом вам нужном месте приложения, своих сервисах и в тч миграциях, если вам нужно.
jazzus, ну допустим разный опыт, разные проекты и тп.
А насчёт миграций советую пересмотреть ваше отношения. Очень удобный инструмент, удобно что потом он и в гит и тп отправляется. Всё работает прозрачно в плане populate my database. Или изменений чего либо.
Миграций вовсе не только для создания и изменения таблиц.
И я могу спокойно знать что моё приложение развернется так, как я хочу. Либо обновится у клиента так как я хочу и тп.
В общем кейс и использование распространенное, не всегда лучший вариант, иногда вредный, нередко полезный и удобный. Каждый раз принимаются решения в зависимости от ситуации.
Вот db:seed для случаев отличных от разработки и тестирования - зло однозначно
Александр Талалаев, чем зло? Так ни одного аргумента не привел. Если ты пропишешь в DatabaseSeeder какие сиды запускать на продакшене то у тебя ТЕХНИЧЕСКИ не будет ошибки. А это 2 строчки кода. Других опасностей и другого "зла" там нет. Да они идеологически для тестовых данных согласен. Поэтому я вначале писал свои классы. Пока не понял что мои классы ПОЛНОСТЬЮ дублируют сиды, а я не люблю дублировать функционал Ларавел.
jazzus, ну как нет. https://laravel.com/docs/8.x/seeding - нужно использовать исключительно для:
-автоматизация тестирования в целом
-сидирования базы данных на машине разработчиков чтобы легче и быстрее строить/дебажить приложения.
ВСЁ. Дальше, будут только костыли, проверка чтобы кто-то не то запустил и тп.
И даже если вы пройдётесь по топу гитхаба(согласен что не показатель, но) вы там в сидерах не увидите ничего, кроме непосредственно сидирования базы данных только для нужд тестирования и разработки.
А вот использования миграций для разных целей, попадается постоянно, тк это намного безопаснее и прямо подразумевает открытым способом изменения в БД(изначально задумывалось только схемы, но..)
Просто даже банальный пример, у чего то в БД нужно поменять допустим префикс, я конечно сделаю миграцию и пройдусь по всем значеним(ну после изменения логики работы уже внутри приложения.)
Вот примеры от других разработчиков:
BookStack - приложение для организации документации и около того, установки и создание ролей поумолчнию.
Spatie - одни из крупных популязаторов и разработчиков пакетов для Ларавел, у них множество примеров, вот на их оф сайте например есть такая миграция да и другие там есть, и в целом они миграции в этом ключе используют.
Laravel-Backpack у себя ив демо и в других штуках бывает
Ну короче. Снова таки, я не говорю что это прям хороший патерн и тд и тп, но довольно часто он таки не антипатерн. позволяет в некотором роде использовать и автоматизацию и гит для контроля БД и тп.
В основном конечно встречается не обычных библиотеках, цмсках и тп, а в продуктовых решениях, где есть кейсы допустим хранения поддерживаемых языков и бывает что-то меняется(ну ввели вначале что просто ru, en и тп, а потом поняли что нужно ru_RU, en_US и тп ) и бывает такую логику удобнее всего писать именно в миграциях из-за прозрачности работы.
А использования db:seed портит многое, нарушает и принципы для чего создан механизм(блин да там даже по набору инструментов видно что это для тестирования и или локальной разработки), легче совершить фатальную ошибку с рефрешем всего, те нужна доп слежка, доп ключи для обхода защиты на продакшене и тп и тд. Да и тупо в сидерах будут лежать не те классы что ожидаешь. Ну камон.
Владислав Лысков, так я с этим по большей же части и согласен. Я больше поражен что предложено использоваться однозначно неподходящий для этого инструмент. Ну и в споре истина рождается, так что.. может я хочу учиться новому. Вот учусь в общении.
Сиды предназначены немного для другого, главная их цель это автоматизация тестирования, поэтому и набор методов соответствующий. Ну и на продакшене по умолчанию их нельзя запустить(только используя ключ --force). Но как тогда разделить сиды для данных и для теста? Короче не вариант.
Вам же можно просто использовать миграции. В них можно писать и логику и тп, в том числе инициализацию и или загрузку каких-либо данных по умолчанию в БД.
