V
Мол, если я буду юзать сиды, то у меня бд будет супер целостной, а если миграции, то нет? Ладно, ясно все.
Size: a a a
2020 May 10
V
миграции это про базу данных. реальные данные эти.. что вот у нас есть изначальный юзер. или какие-то категории.. или справочники забитые... это не совсем про бд. это про логику. в итоге у меня в голове херачить заполнение таблиц данными в миграциях, это как нарушение SRP. Я в принципе готов признать, что это лишь моя прихоть... но нужны веские аргументы )
Уже приводили. За сиды веских аргументов не увидел.
ВС
Мол, если я буду юзать сиды, то у меня бд будет супер целостной, а если миграции, то нет? Ладно, ясно все.
Нет, всё-таки, я задержусь ещё ненадолго. Перечитай, блять, что я написал. При этом постарайся не просто прочитать, а вдуматься в смысл написанного:
И вот ещё что. Даже если сид уже выполнялся, БД должна быть спроектирована так, чтобы эти же данные повторно не попали в неё (уникальный кортеж).
ВС
Я блять ясно написал, что БД не пропустит повторяющиеся кортежи, если будет спроектирована нормально!
V
Ну спроектируй мне таблицу юзеров (без связанных данных, просто одну таблицу юзеров) так, чтобы там был уникальный кортеж (например, ты изначально не включил голову и не юзаешь uuid).
ВС
Это не было аргументом, это было просто замечанием. Пздц, сами раздули, сами обиделись )
ВС
У меня всё
A
Уже приводили. За сиды веских аргументов не увидел.
https://pastebin.com/B9eDEcgy вот пример
А
У меня всё
Дурак ты, дядя Петя. Верующий дурак.
ВС
Дурак ты, дядя Петя. Верующий дурак.
И ты тоже иди нахуй )
V
https://pastebin.com/B9eDEcgy вот пример
Это точечный пример. В этом случае да, повторной вставки не будет. А есть случаи, где надо вставить НЕ связанные данные, а уникального идентификатора (нет uuid и добавлять не хотим) нет, что будешь делать?
A
Это точечный пример. В этом случае да, повторной вставки не будет. А есть случаи, где надо вставить НЕ связанные данные, а уникального идентификатора (нет uuid и добавлять не хотим) нет, что будешь делать?
я свой пример привёл. приведи свой )
V
Вообще-то, я на стороне миграций, зачем мне приводить пример, если любой мой пример будет рабочим в независимости от количества запуска миграций?
А
Если есть uuid, то консольные команды (и то зависит от ситуации, но чаще всего команд хватает). В сидах точно не место данным с продакшна.
R
Как можно проверить подтвердил ли юзер почту или нет?
AO
Как можно проверить подтвердил ли юзер почту или нет?
В таблице вроде есть столбец подтверждения
RK
Как можно проверить подтвердил ли юзер почту или нет?
АЗ
Оооооо срачь про сиды и миграции
АЗ
Запасусь попкорном
АЗ
Вообще мне нравится концепция написания идемпотентных сидеров, и запускать их на каждом деплое. Это удобно тем, что миграции отрабатывают очень быстро, и не возникает ситуации когда код уже выехал, а функционал еще не работает т.к. какая-нибудь миграция сотни тысяч записей в справочниках наполняет, а последующие ждут пока она отработает