ИА
Нахуй map, filter если есть comprehensions
Плохо так разговаривать молодой человек. Неприлично
Size: a a a
2020 May 11
AU
Так вроде вопрос в том и был, чтобы после создания таблицы забить её значениями
AK
Игорь Агапов
Плохо так разговаривать молодой человек. Неприлично
Это стоило записывать звуком, старым, надтреснутым голосом...
МБ
Так вроде вопрос в том и был, чтобы после создания таблицы забить её значениями
Да, но я могу сначала создать один справочник, потом в другой миграции - другой, и надо заполнить их данными при создании, один раз.
ŹR
Да, но я могу сначала создать один справочник, потом в другой миграции - другой, и надо заполнить их данными при создании, один раз.
Seeds это то что тебе надо
МБ
Ну тогда на каждую таблицу он должен быть свой получается
ŹR
Зачем?
IM
Repo.insert_all в первую таблицу, потом Repo.insert_all во вторую, и все в одном seeds.exs
IM
а если это новые данные для уже имеющейся базы, то отдельный mix task по-хорошему надо делать
ŹR
На самом деле весь этот хероку механизм миграций и сидов у меня еще ни в одном проекте полгода не выживаал - обязательно где-то стухнет
ŹR
Но это мы тут уже обсуждали
ŹR
Дата миграции, которые пользуются древними схемами, рассинхрон в порядке наката при разработке более чем одной фичи за раз
ŹR
Кроме того, после появления прода ни сиды ни старые миграции нафик становятся не нужны
ŹR
А до появления прода миграции это тоже такой себе раскиданный по файлам бред
IM
тоже верно, на продакшн базе под нагрузкой миграция данных это процесс размазанный по несколькис деплоям под присмотром DBA, опять же если нет желания базу колом поставить
ŹR
Я где-то пару дней обычно трачу на даатамиграцию на проде
ŹR
Вот только фишка в том, что потом этот код можно просто удалить - он невоспроизводим и нафик не надо его воспроизводить
IM
IM
там где-то ближе к концу описывает товарищ как дата миграции православно делать
ŹR
Крутая статья, я не знал вообще ничего из этого