теоретически-практический вопрос по Джанго
ведем разработку в 2х параллельных ветках
я создал миграцию под номером 0005, товарищ создал миграцию под номером 0005
как резолвить такие "конфликты" при сливании в мастер?
руками
т.е. ему (или мне) надо изменить номер миграции вручную?
проверить что не меняете одни и те же поля
не мерджить же их
вручную объединить схемы
но можно смерджить в одну, без разницы
зависит как остальной код организован в PR
@nimnull если они меняют одни и те же поля то будет конфликт
@Axik я уточнил, см выше
допустим мой код валит продакшн
если одни и те же – сливать в одну миграцию и много общаться
я откатываю свой пулл-реквест
и откатываю свою миграцию
я поэтому и сделал референс
зависит как остальной код организован в PR
ну логично будет тогда переименовывать миграции
если мерж и миграция — фича, то меняйте номера и слейте схему
однако если их 10 штук на каждую задачу
то это беда-беда получается
жизнь — жестокая штука
О, у меня тоже есть вопрос по миграции. Есть ли в джанго возможность автоматической миграции на момент разработки? Такое в .Net есть
не понял, что значит — автоматической?
я хз что там есть в .net
и в какой из его части
на момент разработки вообще я считаю не нужны миграции
ну как сказать
убивайте базу да используйте фактори бой
для фикстур
это как это?
@Axik а под прод потом отдельно писать?
Изменил модель и сразу изменилась таблица. Без файлов миграции
ну как вариант тащемто
всмысле
ПОД ПРОД
у тебя разработка
какой прод нахер
@Infernion нет
а где это в .net?
@Infernion это ужасно, яебу
Пока что не знаю, у меня как-то спросили, а я не ответил. Наверное где-то в asp.net
EntityFramework
Это не часть .net, а сбоку либа
по крайней мере из того что быстро гуглится и похоже на описанное (:
Ага, так вот если такое для джанго?
Хотя, не очень она и крутая, как я погляжу.
миграции Django похожи на то что есть в RoR
Нет, в джанго такого нет. Изменение схемы данных и переход между версиями схемы с помощью миграций — явная процедура
которая отделена от написания кода модели
вообще в step-by-step гайде на оффсайте всё в деталях описано. Как и отдельно в разделе про миграции. Врядли бы кто-то прятал такую фичу.
в контексте миграции данные можно переносить через RunPython?
пример из жизни: рефакторится функционал, затрагивающий 2 таблицы
хз, с 1.8 не работал, в принципе уже пол года джанго не видел, чему несказанно рад
слив на прод - может сломать все к чертовой матери, надо иметь возможность откатиться в предыдущее состояние
хехе) а на что перешел?
на тяжёлые наркотики
а, это data migration теперь так заворачивается
и связан ли переход с убыточностью джанго, или просто проект сменился?
да, данные через него и надо переносить, по новому стилю
мерсирую, буду пробовать
@nimnull а на что перешли?
@Infernion aiohttp
модно, стильно, асинхронно
чота у меня со школы не заладилось ни с мульти-тредами, ни с асинком
респект, что хватает "наснаги" отлаживать весь этот хаос
@Axik на голый? а чем muffin не угодил?
а зачем?
а вообще есть ещё фласк на живенте
И он вроде бы даже быстрее
скорость у нас пока не сильно горит
а фласк - то ещё уёбище
так как у нас монолит и куча сервисов, то главный монолит на фласке с живентом
а новые микросервисы на asyncio p3.4
вот сейчас переходим на 3.5
@Infernion: а за счет чего muffin “вроде как" быстрее?
И aiohttp уже достаточно концепций реализует, чтобы не называться “голым”, что бы это ни значило
@nimnull я имел ввиду флакс с жевентом, что он быстрее
врядли