Как заставить миграции в БД, если некоторые таблицы уже существуют в Django?

У меня есть Python / Django proyect. Из-за некоторых откатов и других смешанных вещей мы оказались в своего рода странном сценарии.

текущий сценарий выглядит следующим образом:

  • DB имеет правильные таблицы
  • DB не может быть откат или падение

  • код обновлен

  • папка миграции -за БД по одной или двум миграциям. (Эти миграции были применены из где-то еще, и это" где-то еще " больше не существует)

  • Я добавляю и изменяю некоторые модели

  • Я бегу makemigrations
  • создаются новые миграции, но это смесь новых таблиц и некоторых таблиц, которые уже существуют в БД.
  • если я перенос он будет жаловаться, что некоторые из таблиц, которые я пытаюсь создать, уже существует.

Что нужно:

To иметь возможность запускать миграции и типа "игнорировать" существующие таблицы и применять новые. Или любым другим способом добиться этого.

Это возможно?

8
django migrate postgresql python

1 ответов

когда вы применяете миграции, Django сохраняет тот факт, что он применял каждую миграцию в таблице с именем django_migrations. Записи в этой таблице должны соответствовать файлам в вашем как обычно, применяя изменения в последнем файле миграции.

  • избавьтесь от любых новых миграций, которые вы только что создали с помощью makemigrations. Теперь закомментируйте или верните в модели все, что не было применено к базе данных, оставив свой код соответствующим тому, что на самом деле находится в базе данных. Теперь вы можете сделать makemigrations и migrate appname --fake и вы получите вещи в синхронизации. Затем раскомментируйте свой новый код и запустите "makemigrations", затем migrate как обычно и изменения будут применены. Если изменения небольшие (например, добавление нескольких полей), иногда это проще всего. Если изменения велики, то это не так....

  • вы можете пойти вперед и (осторожно) внести изменения в базу данных самостоятельно, обновив базу данных. Теперь просто беги!--16--> и если вы не испортили, то все будет в порядке. Опять же, это легко для небольших изменений, а не так легко для сложных.

  • вы можете запустить manage.py sqlmigrate > mychanges.sql. Это генерирует mychanges.sql содержащий все SQL Django будет выполняться против базы данных. Теперь отредактируйте этот файл, чтобы удалить все изменения, которые уже были применены, оставив то, что нужно сделать. Выполните этот SQL, используя pgadmin или psql (надеюсь, вы используете postgresql). Теперь все изменения сделаны.. так что вы можете запустить manage.py migrate --fake, это приведет Django в синхронизации с реальностью, и вы должны быть все готово. Если ваши навыки SQL достаточны, это, вероятно, самое простое решение.

    • я должен добавить два предупреждения:

    во-первых, если вы применяете более позднюю миграцию, например 0003_foobar.py, а затем все не получается, и вы решаете попробовать вернуться и подать заявку 0002_bazbuz.py, затем Django заберет вещи из вашей базы данных. Например, столбец, который вы могли добавить в 0003, будет удален вместе с его данными. Поскольку вы говорите, что не можете потерять данные, будьте очень осторожны с возвращением.

    во-вторых, не бросаться в бега --fake миграция. Убедитесь, что вся миграция, которую вы собираетесь подделать, уже находится в базе данных. Иначе это становится очень запутанным. Если вы сожалеете о фальшивых миграциях и не хотите откатываться, вы можете стереть знания django о фальшивой миграции, удалив эту строку из django_migrations таблица. Это нормально.. если вы понимаете, что делаете. Если вы знаете, что миграция действительно не применялась, тогда все в порядке.

    14