python миграции - Django 1.7 - makemigrations не обнаруживает изменений




12 Answers

Если вы переходите из существующего приложения, которое вы сделали в django 1.6, вам нужно сделать один предварительный шаг (как я узнал), перечисленные в документации:

python manage.py makemigrations your_app_label

Документация не делает очевидным, что вам нужно добавить метку приложения в команду, так как первое, что она вам скажет, это python manage.py makemigrations которая не удастся. Первоначальная миграция выполняется при создании вашего приложения в версии 1.7, но если вы пришли из 1.6, это не было бы выполнено. Подробнее см. «Добавление миграции в приложения» в документации.

rollback empty

Как говорится в названии, я не могу заставить миграцию работать.

Первоначально приложение было под 1,6, поэтому я понимаю, что миграций там не будет, и действительно, если я запустил python manage.py migrate я получаю:

Operations to perform:
  Synchronize unmigrated apps: myapp
  Apply all migrations: admin, contenttypes, auth, sessions
Synchronizing apps without migrations:
  Creating tables...
  Installing custom SQL...
  Installing indexes...
Running migrations:
  No migrations to apply.

Если я внес изменения в какие-либо модели в myapp , он по-прежнему говорит о немиграции, как и ожидалось.

Но если я запускаю python manage.py makemigrations myapp я получаю:

No changes detected in app 'myapp'

Кажется, не имеет значения, что и как я запускаю команду, она никогда не обнаруживает, что приложение имеет изменения, и не добавляет никаких файлов миграции в приложение.

Есть ли способ заставить приложение перейти на миграцию и по существу сказать: «Это моя база для работы» или что-то еще? Или я чего-то не хватает?

Моя база данных является PostgreSQL, если это вообще помогает.




Мое решение не было рассмотрено здесь, поэтому я отправляю его. Я использовал syncdb для проекта - только для его запуска и запуска. Затем, когда я попытался начать использование Django-миграций, он сначала подделывал их, а потом говорил, что это «ОК», но ничего не происходит с базой данных.

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

Затем я только сделал начальную миграцию:

./manage.py makemigrations my_app

с последующим:

./manage.py migrate my_app

Теперь я могу совершать миграции без проблем.




Это своего рода глупая ошибка, но с добавлением дополнительной запятой в конце строки объявления поля в классе модели делает линию недействительной.

Это происходит, когда вы копируете вставку def. из миграции, которая сама определяется как массив.

Хотя, возможно, это помогло бы кому-то :-)




Ответ на этот пост , cdvv7788 Миграции в Django 1.7

Если вы в первый раз переносите это приложение, вы должны использовать:

manage.py makemigrations myappname После этого вы можете сделать:

manage.py migrate. Если у вас было приложение в базе данных, было изменено его модель и не обновлялись изменения в makemigrations, вы, вероятно, еще не перенесли ее. Измените модель на исходную форму, запустите первую команду (с именем приложения) и перенесите ее ... она подделает ее. Как только вы это сделаете, верните изменения в своей модели, запустите makemigrations и снова выполните миграцию, и она должна работать.

У меня была такая же проблема, и работа над этим работала отлично.

Я переместил приложение django в cloud9, и по какой-то причине я никогда не сталкивался с первоначальной миграцией.




Такие люди, как я, которые не любят миграции, могут использовать шаги ниже.

  1. Удалите изменения, которые вы хотите синхронизировать.
  2. Запустите python manage.py makemigrations app_label для начальной миграции.
  3. Запустите python manage.py migrate для создания таблиц перед внесением изменений.
  4. Вставьте изменения, которые вы удаляете с первого шага.
  5. Запустите 2. и 3. шаги.

Если вы смутили какие-либо из этих шагов, прочитайте файлы миграции. Измените их, чтобы исправить вашу схему или удалить ненужные файлы, но не забудьте изменить часть зависимостей следующего файла миграции;)

Надеюсь, это поможет кому-то в будущем.




Может быть, я слишком поздно, но вы пытались создать папку migrations в своем приложении с файлом __init__.py ?




На всякий случай, если у вас есть определенное поле, которое не идентифицируется с помощью makemigrations: дважды проверьте, если у вас есть свойство с тем же именем.

пример:

field = django.db.models.CharField(max_length=10, default = '', blank=True, null=True)

# ... later

@property
def field(self):
    pass

свойство будет «перезаписывать» определение поля, поэтому изменения не будут идентифицироваться с помощью makemigrations




Убедитесь, что ваша модель не abstract . Я действительно совершил эту ошибку, и мне потребовалось некоторое время, поэтому я подумал, что опубликую ее.




У меня была такая же проблема, когда мне приходилось запускать makemigrations дважды и всевозможные странные действия. Оказалось, что корень проблемы состоял в том, что я использовал функцию для установки дат по умолчанию в своих моделях, поэтому миграция обнаруживала изменения каждый раз, когда я запускал makemigrations. Ответ на этот вопрос поставил меня на правильный путь: избегайте макетирования, чтобы воссоздать поле даты




Может быть, это может помочь кому-то, у меня была такая же проблема.

Я уже создал две таблицы с классом сериализатора и представлениями. Поэтому, когда я захотел обновиться, у меня была эта ошибка.

Я сделал следующие шаги:

  1. Я сделал .\manage.py makemigrations app
  2. Я выполнил .\manage.py migrate
  3. Я удалил обе таблицы своих models.py
  4. Я удалил все ссылки на мои таблицы из сериализатора и класса вида.
  5. Я выполнил шаги 1 и 2 .
  6. Я получил мои изменения только в models.py
  7. Я снова выполнил шаг 5 .
  8. Я восстановил все свои изменения.

Если вы работаете с Pycharm, местная история очень полезна.




./manage makemigrations
./manage migrate

Миграция отслеживает изменения в БД, поэтому, если вы переходите из неуправляемого в управляемый, вам нужно убедиться, что таблица базы данных youre актуальна в отношении модели, с которой вы имеете дело.

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

ПОМНИТЕ: если у вас есть миграция, которая заканчивается с _001 в вашей IDE и _003 в вашей базе данных. Django увидит, закончится ли переход на _004 для обновления.

2 (миграция кода и db) связаны и работают в тандеме.

Счастливое кодирование.




Добавление моего 2c, поскольку ни один из этих решений не работал для меня, но это было ...

Я только что запустил manage.py squashmigrations и удалил старые миграции (как файлы, так и строки в таблице базы данных django.migrations).

Это оставило такую ​​строку в последнем файле миграции:

replaces = [(b'my_app', '0006_auto_20170713_1735'), (b'my_app', '0007_auto_20170713_2003'), (b'my_app', '0008_auto_20170713_2004')]

Это, по-видимому, запутало Django и вызвало странное поведение: запуск manage.py makemigrations my_app воссоздал первоначальную миграцию, как будто ничего не существовало. Исправлена ​​проблема с replaces... строки!




Related