RC
мне кажется или миграции джанги это инструмент только если на проекте от одного до двух разработчиков
Size: a a a
2020 December 16
DB
Просто в Джанге нет нормального способа задать другое название для этой таблицы (
флешбеки recorder.ensure_schema
ED
Я: да пусть все миграции от двух проектов, у которых общая база, хранятся в одной таблице django_migrations. Крайне маловероятно, что у нас будут миграции с одинаковым номером и названием
Django: 0001_initial.py
Django: 0001_initial.py
Сабмодули или похожие инструменты решают проблему. Если есть у двух сервисов общий набор моделей для единой БД, то делается отдельная репа для этих моделей, а в проекты подключается в виде сабмодулей или как-то ещё.
ED
мне кажется или миграции джанги это инструмент только если на проекте от одного до двух разработчиков
Достаточно просто иметь монолитную архитектуру, и можно хоть сотню разработчиков на джанго миграции посадить.
RC
просто неясно зачем, инструмент удобный если есть доступ в базу сразу применять (и не страшно)
на крупных проектах кажется удобнее чистым sql’ем работать
на крупных проектах кажется удобнее чистым sql’ем работать
ED
Ну нет. Даже Alembic с его косяками лучше, чем сырой SQL.
RC
это если ревью у дба нет
AK
это если ревью у дба нет
Можно проверить вывод sqlmigrate и прописать в миграцию SQL, если что-то не устраивает
2020 December 18
E
Вот считается, что poetry.lock файл надо хранить в репозитории. А если над проектом работают люди с разных платформ, для которых зависимости ставятся по-разному. Допустим windows и linux. И на windows зависимость ставится из локального wheel-файла, а на linux из pypi. В таком случае lock файл у каждого будет свой и что делать? Каждый раз его обновлять и перезаписывать при затягивании не своих изменений?
E
вот как с numpy, после того как в винде сломали С-рантайм в одном из обновлений, numpy c openblas перестал работать и надо ставить с mkl, а он есть только неофициальный.
lock файл в таком случае оказывается в перманентном конфликте между разработчиками на разных платформах.
lock файл в таком случае оказывается в перманентном конфликте между разработчиками на разных платформах.
MK
костыль — сказать виндузятником не коммитить конкретно это изменение в лок
MK
ещё костыль — поднять свой pypi где будут лежать правильные колеса
MK
а вообще — завести ишью
E
а вообще — завести ишью
issue на что?
Если в poetry, то я даже не знаю как его верно сформулировать.
Если в poetry, то я даже не знаю как его верно сформулировать.
E
По моему очевидно, что могут быть платформо-зависимые зависимости и lock-файл будет постоянно у всех "портиться", потому что он один глобальный.
MK
как-то так, наверное — разрешите хранить в лок файле платформо-зависимые пути?
MK
а как у тебя это в прожект файле сейчас прописано вообще?
E
а как у тебя это в прожект файле сейчас прописано вообще?
сейчас там вообще костыль такой дикий. wheel файл задан явно причем только для одной версии numpy, потому что poetry не умеет find-links как pip, там можно только явно path к файлу задать, а не path к директории с колёсами.
MK
сейчас там вообще костыль такой дикий. wheel файл задан явно причем только для одной версии numpy, потому что poetry не умеет find-links как pip, там можно только явно path к файлу задать, а не path к директории с колёсами.
погоди, а для линукса как?