Почему возникает ошибка при миграции БД в Django 1.11.2 после клонирования с Github?

Question

[Irina Travel]

Привет всем!

Подскажите, пожалуйста, в чём может быть проблема. Ситуация такая: есть проект в приватном репозитории GitHub на Django 1.11.2 (не пустой, в активной разработке). Делаю git clone для него (заливаю с нуля), открываю в PyCharm и ввожу в консоли python manage.py migrate.

На компе (Win8.1 x64) установлен PostgreSQL 9.6.x, создан пользователь/таблица, в проекте (settings.py) всё прописано, тестовое соединение в настройках PyCharm — success.

Вижу вот эту ошибку:

$ python manage.py migrate

Traceback (most recent call last):
  File "...\Programs\Python\Python36-32\lib\site-packages\django\db\backends\utils.py", line 65, in execute
    return self.cursor.execute(sql, params)
psycopg2.ProgrammingError: ОШИБКА:  отношение "citizenship_citizenship" не существует
LINE 1: ...enship_citizenship"."is_available_for_order" FROM "citizensh...
                                                             ^
The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "manage.py", line 22, in <module>
    execute_from_command_line(sys.argv)
  File "...\Programs\Python\Python36-32\lib\site-packages\django\core\management\__init__.py", line 363, in execute_from_command_line
    utility.execute()
  File "...\Programs\Python\Python36-32\lib\site-packages\django\core\management\__init__.py", line 355, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "...\Programs\Python\Python36-32\lib\site-packages\django\core\management\base.py", line 283, in run_from_argv
    self.execute(*args, **cmd_options)
  File "...\Programs\Python\Python36-32\lib\site-packages\django\core\management\base.py", line 327, in execute
    self.check()
  File "...\Programs\Python\Python36-32\lib\site-packages\django\core\management\base.py", line 359, in check
    include_deployment_checks=include_deployment_checks,
  File "...\Programs\Python\Python36-32\lib\site-packages\django\core\management\commands\migrate.py", line 62, in _run_checks
    issues.extend(super(Command, self)._run_checks(**kwargs))
  File "...\Programs\Python\Python36-32\lib\site-packages\django\core\management\base.py", line 346, in _run_checks
    return checks.run_checks(**kwargs)
  File "...\Programs\Python\Python36-32\lib\site-packages\django\core\checks\registry.py", line 81, in run_checks
    new_errors = check(app_configs=app_configs)
  File "...\Programs\Python\Python36-32\lib\site-packages\django\core\checks\urls.py", line 16, in check_url_config
    return check_resolver(resolver)
  File "...\Programs\Python\Python36-32\lib\site-packages\django\core\checks\urls.py", line 26, in check_resolver
    return check_method()
  File "...\Programs\Python\Python36-32\lib\site-packages\django\urls\resolvers.py", line 254, in check
    for pattern in self.url_patterns:
  File "...\Programs\Python\Python36-32\lib\site-packages\django\utils\functional.py", line 35, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "...\Programs\Python\Python36-32\lib\site-packages\django\urls\resolvers.py", line 405, in url_patterns
    patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
  File "...\Programs\Python\Python36-32\lib\site-packages\django\utils\functional.py", line 35, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "...\Programs\Python\Python36-32\lib\site-packages\django\urls\resolvers.py", line 398, in urlconf_module
    return import_module(self.urlconf_name)
  File "...\Programs\Python\Python36-32\lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 978, in _gcd_import
  File "<frozen importlib._bootstrap>", line 961, in _find_and_load
  File "<frozen importlib._bootstrap>", line 950, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 655, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 205, in _call_with_frames_removed
  File "...\django_trt\django_trt\urls.py", line 10, in <module>
    url(r'^account/', include('clients.urls')),
  File "...\Programs\Python\Python36-32\lib\site-packages\django\conf\urls\__init__.py", line 50, in include
    urlconf_module = import_module(urlconf_module)
  File "...\Programs\Python\Python36-32\lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 978, in _gcd_import
  File "<frozen importlib._bootstrap>", line 961, in _find_and_load
  File "<frozen importlib._bootstrap>", line 950, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 655, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 205, in _call_with_frames_removed
  File "...\django_trt\clients\urls.py", line 6, in <module>
    from .views import *
  File "...\django_trt\clients\views.py", line 9, in <module>
    from .forms import ClientChangeForm
  File "...\django_trt\clients\forms.py", line 73, in <module>
    class ClientChangeForm(forms.ModelForm):
  File "...\django_trt\clients\forms.py", line 74, in ClientChangeForm
    class Meta:
  File "...\django_trt\clients\forms.py", line 149, in Meta
    'class': 'citizenship-select',
  File "...\Programs\Python\Python36-32\lib\site-packages\django\forms\widgets.py", line 544, in __init__
    self.choices = list(choices)
  File "...\Programs\Python\Python36-32\lib\site-packages\django\db\models\query.py", line 250, in __iter__
    self._fetch_all()
  File "...\Programs\Python\Python36-32\lib\site-packages\django\db\models\query.py", line 1105, in _fetch_all
    self._result_cache = list(self._iterable_class(self))
  File "...\Programs\Python\Python36-32\lib\site-packages\django\db\models\query.py", line 53, in __iter__
    results = compiler.execute_sql(chunked_fetch=self.chunked_fetch)
  File "...\Programs\Python\Python36-32\lib\site-packages\django\db\models\sql\compiler.py", line 886, in execute_sql
    raise original_exception
  File "...\Programs\Python\Python36-32\lib\site-packages\django\db\models\sql\compiler.py", line 876, in execute_sql
    cursor.execute(sql, params)
  File "...\Programs\Python\Python36-32\lib\site-packages\django\db\backends\utils.py", line 65, in execute
    return self.cursor.execute(sql, params)
  File "...\Programs\Python\Python36-32\lib\site-packages\django\db\utils.py", line 94, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "...\Programs\Python\Python36-32\lib\site-packages\django\utils\six.py", line 685, in reraise
    raise value.with_traceback(tb)
  File "...\Programs\Python\Python36-32\lib\site-packages\django\db\backends\utils.py", line 65, in execute
    return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: ОШИБКА:  отношение "citizenship_citizenship" не существует
LINE 1: ...enship_citizenship"."is_available_for_order" FROM "citizensh...
                                                             ^

Также неясно, почему не делается первоначальная инициализация БД (где auth/sessions/etc таблицы создаются)? Как вообще нужно организовывать работу с git для Django проекта? Что гитигнорить, а что наоборот оставлять?

Буду рада любой помощи...

Comments

[Irina Travel]

То есть, получается, что без тех миграций, которые были в папках migrations в каждом приложении — больше никак БД не восстановить? Просто ни одна из команд (в хелпе manage.py) не помогает сбросить этот кэш что ли, который не даёт сделать первоначальную инициализацию БД...

Answer 1

[Евгений]

Ошибка в миграциях где-то. Ответить на вопрос из озвученных исходных данных невозможно. Можно только видя весь код и базу, используя команды showmigrations, migrate --fake-initial, migrate, migrate --fake попытаться решить ситуацию.

Comments

[Irina Travel]

Дело в том, что папки migrations в каждом приложении — были загитигноренны, то есть при клонировании их нет. Всякие команды (типа showmigrations, migrate --fake-initial, migrate --fake) показывают ту же самую ошибку из первого поста.

Получается, что без файлов миграций, которые остались видимо на компе одного из предыдущих кодеров, кто с проектом работал, —сделать заново миграции просто не представляется возможным?! Жесть..

[Евгений]

Irina Travel: Если так, то бегите от этого проекта. Это будет наименьшая из ваших проблем!
Вообще, миграции можно сгенерировать заново: makemigrations. Но скорее всего, дальше возникнут еще большие проблемы, если оригинальный разработчик был настолько оригинален.

[sim3x]

Irina Travel: Если в БД на продакшене уже есть данные и в репах нет миграций, то дело плохо

[Евгений]

sim3x: Ну, почему. Можно очистить историю миграций в продакшене и начать заново. Я постоянно так делаю, чтобы не копить цепочки миграций, тесты ускорить, и т.д. Но одно дело, конечно, когда это делается штатно и обдуманно. Другое дело, что там этот разработчик навертел.

[Irina Travel]

Хех.. поняла вас.. Вообщем, к этому всё и шло, но мало ли есть "серебрянная пуля")))

Я так поняла, что единственный вариант — это создать схему БД вручную (добавлять планомерно таблицы, на которые ругается консоль), чтобы исправить ошибку "связь не найдена" и попробовать ещё раз makemigrations сделать, но потом нарваться на другие проблемы, которые были в файлах миграций прошлого кодера?

А может подскажите, пожалуйста, какие папки/файлы нельзя гитигнорить в проектах на Django, чтобы передавать проект без проблем новому кодеру (через git clone) и не было подобных ситуаций (когда работа над проектом возможна только на компе того кодера, кто загитигнорил папки migrations)?

[sim3x]

Евгений:

не копить цепочки миграций

migration-squashing ?

[Евгений]

Irina Travel: Не надо вручную создавать. Сделайте makemigrations и мигрируйте по новой. У вас то база пустая. С продакшном, если он есть, будет сложнее. Лучше и не пытаться, без опыта будет тяжело и можно накосячить.

В git добавляется то, что пишется руками и то, без чего не обойтись другим разработчикам. Не добавляются автогенерируемые файлы (например, *.pyc, __pycache__, *.bak, и т.п.). Миграции, естественно, должны быть в Git. Это обычные исходники, многие миграции вообще руками пишутся, и они должны быть у всех разработчиков - так что это совершенно понятно любому вменяемому человеку. Судя по всему, предыдущий автор проекта таковым не был, и его надо бы занести в черный список. Миру будет лучше без таких разработчиков, им только улицы подметать можно доверить, да и то под надзором.

[Евгений]

sim3x:

migration-squashing

Оно просто все миграции в одну большую объединяет. А по сути, спустя какое-то время огромное количество миграций не только не нужно, но и вредно. Например, тесты дольше работают. Старые зависимости не удалить. И т.п. Раз в год где-то проще начинать историю миграций с нуля.

[sim3x]

Евгений: в какой-то момент времени вы можете оставить проект в такой же ситуации, как указана в вопросе

Не_надо_так.жпг

[Евгений]

sim3x: Почему? Это делается единовременно, при помощи скриптов и уведомления всех участвующих в проекте. Причем, не я автор методики, я и читал об этом, и приходя в другие проекты сталкивался с таким же подходом.

Пишутся скрипты, чтобы автоматически очистить историю старых миграций, удаляем старые миграции, добавляем в репо новые чистые. Если делать грамотно, то такой ситуации, как у автора поста не возникнет.

А иначе придется за собой тащить воз и тележку старых зависимостей. Использовал 5 лет назад какой-нибудь пакет django-cool-tagging, который давно протух? Извини, не можешь удалить его из requirements.txt, потому что он входит в граф миграций.

[Irina Travel]

Евгений: спасибо, очень хорошо написали :)

А как вы делаете "раз в год [...] историю миграций с нуля", если не используете migration-squashing и прочее? Поделитесь, пожалуйста, алгоритмом.

[Евгений]

Irina Travel:
1. Пишу скрипт из одной строки типа clean-migrations.sql:

DELETE FROM django_migrations WHERE app_name IN (перечисляем наши приложения)

2. Удаляю все из миграций
3. Запускаю makemigrations, чтобы создать начальные миграции для всех приложений
4. Во всех окружениях (production, staging, у разработчиков), сначала выполняется скрипт командой psql < clean-migrations.sql, затем migrate --fake-initial

Вроде все. Детали не помню, т.к. каждый раз и в каждом проекте делаю это немного по-разному. Главное все сделать одновременно и согласовнно со всеми, если разработчиков более одного. И забэкапить базу перед началом.

[Евгений]

Ну и конечно, это способ не для публичных переиспользуемых приложений. Потому что если приложение раздается через PyPI или GitHub, то конечно, придется хранить историю миграций вечно. Но я пока в больших open source проектах не участвовал, все мои проекты - закрытые, и можно запросто сделать такой финт, облегчив репозиторий от старого хлама.

[sim3x]

https://simpleisbetterthancomplex.com/tutorial/201...

[Евгений]

sim3x: Все то же самое, только немного другими словами. У меня тоже нет устоявшейся процедуры, каждый раз импровизирую. Может надо написать автоматизированный инструмент уже, и передать его в Django. :)

[sim3x]

Евгений:
Все же я б не стал делать такую операцию рутинной ака раз в год и тд

[Irina Travel]

Огромное спасибо за опыт и ссылку. Сразу всё по местам в голове разложилось!

[sim3x]

Евгений: в той статейке, просто без прямой интервенции в СУБД автор обходится

[Евгений]

sim3x: Да, но суть та же самая. migrate app zero --fake делает тот же delete. Вопрос только записи и удобства. Я своим скриптом сразу все миграции всех приложений очищаю, мне так понятнее и проще.

[sim3x]

Евгений: и вы используете правильную субд

[Vic Shóstak]

Евгений sim3x ребят, а не подскажите по такой же проблеме вот тут: https://ru.stackoverflow.com/questions/683163/Как-... (чтобы не плодить темы на тостере, нашёл в поиске этот вопрос, но у меня всё ок, миграции в папках на гите).