Всем привет.
Есть установленная django 1.11.4, в официальном туториале приведен пример изначальной миграции как: python manage.py migrate. Все бы ничего, но такой способ создает помимо необходимых записей в базу таблиц дефолтных приложений (admin, auth, contenttypes…) миграции в /site-packages/django/ соответствующих приложений. И мне не совсем понятно, зачем. Вряд ли я (и 99% других пользователей) будут мигрировать модели искаробочных приложений. Соответственно, такое поведение, на мой взгляд, избыточно.
В документации я нашел, что можно сделать: manage.py migrate –run-syncdb. Пример юзкейса там приведен несколько другой (экономия времени на проектах с большим количеством моделей), но вроде бы он делает то, что необходимо.
Еще есть два интересных флага: –fake и –fake-migrations. Первый, как я понял, для того, чтобы отметить миграцию как выполненную, но на самом деле запись в бд не производить. И второй, чтобы интегрировать миграции в проект, который ранее существовал без миграций.
В связи со всем этим у меня возникает несколько вопросов:
1. Является ли migrate –run-syncdb подходящим решением для поставленной задачи? Может ли такой подход в будущем привести к каким-то проблемам?
2. Кому могут понадобиться миграции в bult-in applications кроме разработчиков django?
3. Необходимо ли каким-то образом после –run-syncdb использовать –fake-migrations в моем случае?
4. Почему manage.py migrate без флагов в пустом проекте создает файлы миграции самостоятельно, без необходимости вызывать makemigrations напрямую?
5. Если поочередно писать manage.py makemigrations <builtin_app_name> (auth) то миграции отображаются и выполняются, но если просто написать manage.py makemigrations - то ничего не происходит? И миграции не создаются. А, наверное, должны были бы поочередно создаваться миграции для всех подключенных приложений (включая искаробочные). Или не должны?
6. Что конкретно делает –fake-migrations, если можно на примере?
Спасибо за помощь.
Полная версия: несколько вопросов по initial migrations
xzvf
Скажите, а как по-вашему Джанга должна определять, где юзерские модули, а где библиотечные?
Скажите, а как по-вашему Джанга должна определять, где юзерские модули, а где библиотечные?
Способов много, самый простой и очевидный - все приложения, начинающиеся с ‘django.*’ считать нативными, остальное детектить как third-party.
А по теме у вас есть, что сказать?
А по теме у вас есть, что сказать?
xzvfА я вам по теме и говорю. Показать вам сотню-другую пакетов в PyPi, которые начинаются с django*? django-debugtoolbar, django-extrensions и пр., которые не входят в состав джанги сами по себе, это чьи-то частные разработки, почему джанга по каким-то весьма сомнительным причинам не должна создавать для них миграции? Вообще ваша проблема надумана. Чем вам мешают каталоги с миграциями?
А по теме у вас есть, что сказать?
>> Показать вам сотню-другую пакетов в PyPi, которые начинаются с django*?
Вы какой-то ерундой занимаетесь, ей-богу. Кроме того, меня не верно цитируете. Вы забыли ТОЧКУ. Не django* (так действительно могут называться какие угодно либы), а django.* - то есть подлибы фреймворка django. Один пакет с названием django можно было бы оставить зарезервированным (подобные решения приняты не в одном месте этого замечательного фреймворка, но не здесь).
>> Вообще ваша проблема надумана. Чем вам мешают каталоги с миграциями?
Ну, вообще-то это концептуально кривовато. Хотел с кем-то обсудить. А можете что-то ответить по моим пронумерованным вопросам?
Вы какой-то ерундой занимаетесь, ей-богу. Кроме того, меня не верно цитируете. Вы забыли ТОЧКУ. Не django* (так действительно могут называться какие угодно либы), а django.* - то есть подлибы фреймворка django. Один пакет с названием django можно было бы оставить зарезервированным (подобные решения приняты не в одном месте этого замечательного фреймворка, но не здесь).
>> Вообще ваша проблема надумана. Чем вам мешают каталоги с миграциями?
Ну, вообще-то это концептуально кривовато. Хотел с кем-то обсудить. А можете что-то ответить по моим пронумерованным вопросам?
xzvfЯ ерундой занимаюсь? Это вы какую-то себе проблему придумали “концептуальную” и думаете, что родные джанговские приложения вроде django.contrib.auth чем-то особенным отличаются от остальных. А ничем они не отличаются, их точно так же как остальные нужно поддерживать миграциями. Завтра выйдет новая версия джанги, в модель сессии юзера добавят поле и? Как вы собираетесь вашу уже существующую БД привести в соответствие с новой схемой если у вас нет истории миграций?
Вы какой-то ерундой занимаетесь
О, вот это уже по делу 
Я исходил из того, что наверняка для разработки и дальнейшей поддержки более менее долгосрочного проекта будет взята ближайшая LTS версия фреймворка и, таким образом, вряд ли встроенные приложения будут мигрировать годами.
>> Как вы собираетесь вашу уже существующую БД привести в соответствие с новой схемой если у вас нет истории миграций?
Раз в 3 года можно конечно и руками что-то поправить, но в целом согласен.
Если вам не трудно, могли бы вы мне помочь с вопросами 4, 5, 6?
Я исходил из того, что наверняка для разработки и дальнейшей поддержки более менее долгосрочного проекта будет взята ближайшая LTS версия фреймворка и, таким образом, вряд ли встроенные приложения будут мигрировать годами.>> Как вы собираетесь вашу уже существующую БД привести в соответствие с новой схемой если у вас нет истории миграций?
Раз в 3 года можно конечно и руками что-то поправить, но в целом согласен.
Если вам не трудно, могли бы вы мне помочь с вопросами 4, 5, 6?