Django - makemigrations - изменений не обнаружено


142

Я пытался создать миграции в существующем приложении с помощью команды makemigrations, но она выводит «Изменений не обнаружено».

Обычно я создаю новые приложения с помощью startappкоманды, но не использовал ее для этого приложения, когда создавал его.

После отладки я обнаружил, что он не создает миграцию, потому что migrationsпакет / папка отсутствует в приложении.

Было бы лучше, если он создаст папку, если ее нет или мне что-то не хватает?


13
Вы добавили свое приложение в INSTALLED_APPS?
wolendranh

6
Да, это впервые в установленном приложении, лучше использовать, makemigrations <myapp>как также указал Аласдер.
Dilraj

1
Удалить 'abstract = True' :)
GrvTyagi 03

'makemigrations' не сработал. 'makemigrations <myapp>' сработал
Aseem

В моем случае изменения не были обнаружены, потому что классы внутри models.py не унаследованы от models.Model. После того, как классы внутри models.py наследовались от models.Model, например MyDataClass (models.Model), проблема была решена. Тривиально, но надеюсь, что это кому-то поможет.
ЛКМ

Ответы:


270

Чтобы создать начальные миграции для приложения, запустите makemigrationsи укажите имя приложения. Папка миграции будет создана.

./manage.py makemigrations <myapp>

Ваше приложение должно быть включено INSTALLED_APPSпервым (внутри settings.py).


15
Есть идеи, почему они <иногда> заставляют нас указывать приложение?
maazza

41
@maazza необходимо указать имя приложения, если в приложении нет migrationsпапки. Это могло произойти, если вы создали приложение вручную или обновили старую версию Django, в которой не было миграций.
Alasdair

13
@maazza На самом деле вам нужен пакет python с __init__.pyименем migrations в приложении.
Jibin

3
Похоже, что Django должен обрабатывать автоматически.
duality_ 04

1
@duality_ это является дизайн - Django не предполагает , что вы хотите миграции для вашего приложения. Если он создал миграции для всех приложений, это могло привести к ошибкам при запуске migrate.
Alasdair

50

Моя проблема (и ее решение) все же отличались от описанных выше.

Я не использовал models.pyфайл, а создал modelsкаталог и создал там my_model.pyфайл, в который я поместил свою модель. Django не смог найти мою модель, поэтому он написал, что никаких миграций применять нельзя.

Мое решение было: в my_app/models/__init__.pyфайле я добавил эту строку: from .my_model import MyModel


Это оказалось решением и для меня, но я не понимаю, почему это так. Есть ли у кого-нибудь представление о том, что может быть причиной этого?
Пол ин 'т Хаут,

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

@ KarinaKlinkevičiūtė что, если мне нужно удалить такие модели?
Даниил Машкин

@DaniilMashkin Я полагаю, вам также нужно удалить импорт. Это один из способов структурирования вашего проекта (не единственный), и вам придется решать дополнительные задачи, которые
связаны

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

45

Существует несколько возможных причин, по которым django не определяет, что нужно перенести во время выполнения makemigrationsкоманды.

  1. Папка миграции. В вашем приложении необходим пакет миграции.
  2. INSTALLED_APPS Вам нужно, чтобы ваше приложение было указано в INSTALLED_APPS.dict
  3. Многословие начинается с бегства makemigrations -v 3за многословие. Это может пролить свет на проблему.
  4. Полный путь В INSTALLED_APPSрекомендуется указать полный путь конфигурации приложения модуля apply.apps.MyAppConfig
  5. --settings , возможно, вы захотите убедиться, что установлен правильный файл настроек:manage.py makemigrations --settings mysite.settings
  6. укажите имя приложения, явно укажите имя приложения manage.py makemigrations myapp- это сузит количество миграций только для приложения и поможет вам изолировать проблему.
  7. модель мета проверить вы имеете право app_labelв вашей модели мета

  8. Отладка django отладка основного скрипта django. Команда makemigrations довольно проста. Вот как это сделать в pycharm . изменить определение сценария соответствующим образом (например: makemigrations --traceback myapp)

Несколько баз данных:

  • Db Router при работе с django db router класс маршрутизатора (ваш собственный класс маршрутизатора) должен реализовывать allow_syncdbметод.

makemigrations всегда создает миграции для изменений модели, но если allow_migrate () возвращает False,


1
Рассмотрено множество сценариев проблемы, должен быть принятый ответ.
Кришх

Другая возможность: импортируется неправильное имя, т.е. импортируется поле из форм вместо полей, или импортируется модель из форм вместо моделей. Пример: from recurrence.forms import RecurrenceFieldа должно было быть from recurrence.fields import RecurrenceField.
hlongmore

Еще одна причина. Убедитесь, что модель используется в маршруте для веб-сайта (через администратора или иным образом). « makemigrationsСкрипт ищет модели, которые подключены из urls.py». Найдено здесь stackoverflow.com/questions/43093651/…
Кайл

Пример cmd:python manage.py makemigrations -v 3 <app_name>
Чарли 木匠

Когда я добавляю таблицу, а затем добавляю внешний ключ, одновременно ссылаюсь на эту новую таблицу. Он должен быть разделен на 2 этапа: предварительный этап: добавьте INSTALLED_APPS в настройки. 1) создайте новую таблицу: python manage.py makemigrations <app_name>; 2) добавить внешний ключ: python manage.py makemigrations
Чарли 木匠

26

Я читал много ответов на этот вопрос, в которых часто говорилось, что нужно просто работать makemigrationsдругими способами. Но для меня проблема была в Metaподклассе моделей.

У меня есть конфигурация приложения, в которой говорится label = <app name>apps.pyфайле, рядом models.pyи views.pyт. Д.). Если случайно ваш мета-класс не имеет той же метки, что и метка приложения (например, из-за того, что вы разделяете одно слишком большое приложение на несколько), никаких изменений не обнаруживается (и вообще нет полезного сообщения об ошибке). Итак, в моем модельном классе теперь есть:

class ModelClassName(models.Model):

    class Meta:
        app_label = '<app name>' # <-- this label was wrong before.

    field_name = models.FloatField()
    ...

Здесь запускаем Django 1.10.


13

Это комментарий, но, вероятно, это должен быть ответ.

Убедитесь, что имя вашего приложения находится в settings.py, INSTALLED_APPSиначе, что бы вы ни делали, миграции не будут выполняться.

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    'blog',
]

Затем запустите:

./manage.py makemigrations blog

но он создает имя таблицы как 'appname_modelname', когда мы запускаем команду 'manage.py migrate'
Даниал

См модели варианты мета изменить название таблицы
Стефен

11

У меня была другая проблема, не описанная здесь, которая сводила меня с ума.

class MyModel(models.Model):
    name = models.CharField(max_length=64, null=True)  # works
    language_code = models.CharField(max_length=2, default='en')  # works
    is_dumb = models.BooleanField(default=False),  # doesn't work

У меня была завершающая ',' в одной строке, возможно, от копирования и вставки. Строка с is_dumb не создает миграцию модели с помощью './manage.py makemigrations', но также не выдает ошибку. После удаления "," все заработало, как ожидалось.

Так что будьте осторожны при копировании и вставке :-)


Завершающая запятая может вызвать ошибки и в другом месте; запятая делает оператор кортежем, поэтому is_dumbравен (models.BooleanField(default=False), )which makemigrationsне знает, как преобразовать в столбец базы данных.
hlongmore

8

Иногда ./manage.py makemigrationsбывает лучше, ./manage.py makemigrations <myapp>потому что он может обрабатывать определенные конфликты между приложениями.

Эти случаи происходят тихо, и требуется несколько часов, swearingчтобы понять истинный смысл страшного No changes detectedсообщения.

Следовательно, гораздо лучше использовать следующую команду:

./manage.py makemigrations <myapp1> <myapp2> ... <myappN>


7

Я скопировал таблицу из-за пределов django, и для класса Meta по умолчанию установлено значение «managed = false». Например:

class Rssemailsubscription(models.Model):
    id = models.CharField(primary_key=True, max_length=36)
    ...
    area = models.FloatField('Area (Sq. KM)', null=True)

    class Meta:
        managed = False
        db_table = 'RSSEmailSubscription'

После изменения manged на True, makemigrations начал принимать изменения.


4
  1. Убедитесь, что ваше приложение упомянуто в installed_apps в settings.py
  2. Убедитесь, что ваш класс модели расширяет модели.

2

Я решил эту проблему следующим образом:

  1. Удалите файл "db.sqlite3". Проблема здесь в том, что ваша текущая база данных будет удалена, поэтому вам придется переделывать ее снова.
  2. В папке миграции вашего отредактированного приложения удалите последний обновленный файл. Помните, что первый созданный файл: «0001_initial.py». Например: я создал новый класс и зарегистрировал его с помощью процедуры «makemigrations» и «migrate», теперь был создан новый файл с именем «0002_auto_etc.py»; стереть.
  3. Перейдите в папку « pycache » (внутри папки миграции) и сотрите файл «0002_auto_etc.pyc».
  4. Наконец, перейдите в консоль и используйте «python manage.py makemigrations» и «python manage.py migrate».

2

Я забыл привести правильные аргументы:

class LineInOffice(models.Model):   # here
    addressOfOffice = models.CharField("Корхоная жош",max_length= 200)   #and here
    ...

в models.py, а затем он начал сбрасывать этот надоедливый

В приложении myApp изменений не обнаружено


2

Другая возможная причина заключается в том, что у вас были определенные модели в другом файле (не в пакете), и вы не ссылались на них в другом месте.

Для меня простое добавление from .graph_model import *в admin.py(где graph_model.pyбыл новый файл) решило проблему.


2

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

rm -r */migrations/*
rm db.sqlite3
python3 manage.py makemigrations
No changes detected

Whaat ??

Я также по ошибке удалил все __init__.pyфайлы :( - Все снова заработало после того, как я вошел и:

touch ads1/migrations/__init__.py

Затем для каждого из моих приложений makemigrationsснова заработало.

Оказывается, я вручную создал новое приложение, скопировав другое, и забыл поместить его __init__.pyв migrationsпапку, и это убедило меня в том, что все было шатко, что привело к тому, что я усугубил ситуацию, rm -rкак описано выше.

Надеюсь, это поможет кому-нибудь в течение нескольких часов ругать ошибку «Изменений не обнаружено».


1

Решение в том, что вы должны включить свое приложение в INSTALLED_APPS.

Я пропустил это и обнаружил ту же проблему.

после указания имени моего приложения миграция прошла успешно

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'boards',
]

обратите внимание, я упомянул доски в последнем, это мое имя приложения.


1

INSTALLED_APPS = [

'blog.apps.BlogConfig',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',

]

убедитесь, что 'blog.apps.BlogConfig' (он включен в ваш settings.py, чтобы выполнить миграцию вашего приложения)

затем запустите блог python3 manage.py makemigrations или имя вашего приложения


1

У вас тоже может возникнуть очень глупая проблема - определить два class Metaв вашей модели. В этом случае любые изменения первого не будут применены при запуске makemigrations.

class Product(models.Model):
    somefield = models.CharField(max_length=255)
    someotherfield = models.CharField(max_length=255)

    class Meta:
        indexes = [models.Index(fields=["somefield"], name="somefield_idx")]

    def somefunc(self):
        pass

    # Many lines...

    class Meta:
        indexes = [models.Index(fields=["someotherfield"], name="someotherfield_idx")]

1

Я знаю, что это старый вопрос, но я боролся с этой же проблемой весь день, и мое решение было простым.

Моя структура каталогов была примерно такой:

apps/
   app/
      __init__.py
      app_sub1/
           __init__.py
           models.py
      app_sub2/
           __init__.py
           models.py
      app_sub3/
           __init__.py
           models.py
   app2/
      __init__.py
      app2_sub1/
           __init__.py
           models.py
      app2_sub2/
           __init__.py
           models.py
      app2_sub3/
           __init__.py
           models.py
    main_app/
      __init__.py
      models.py

И поскольку все другие модели, вплоть до той, с которой у меня возникла проблема, импортировались куда-то еще, и в конечном итоге импорт из main_appкоторой был зарегистрирован в INSTALLED_APPS, мне просто повезло, что все они работали.

Но так как я только добавил друг appк INSTALLED_APPSи неapp_sub* когда я , наконец , добавили новые модели файл , который не был импортирован в другом месте, Django полностью игнорировали его.

Мое исправление заключалось в добавлении models.pyфайла в базовый каталог каждого из appтаких ...

apps/
   app/
      __init__.py
      models.py <<<<<<<<<<--------------------------
      app_sub1/
           __init__.py
           models.py
      app_sub2/
           __init__.py
           models.py
      app_sub3/
           __init__.py
           models.py
   app2/
      __init__.py
      models.py <<<<<<<<<<--------------------------
      app2_sub1/
           __init__.py
           models.py
      app2_sub2/
           __init__.py
           models.py
      app2_sub3/
           __init__.py
           models.py
    main_app/
      __init__.py
      models.py

а потом добавить from apps.app.app_sub1 import *и так далее на каждый appуровеньmodels.py файлов .

Блех ... это заняло у меня ТАКОЕ много времени, чтобы понять, и я нигде не мог найти решение ... Я даже перешел на страницу 2 результатов Google.

Надеюсь, это кому-то поможет!


1

Еще один крайний случай и решение:

Я добавил логическое поле, и в то же время добавил ссылающееся на него @property с тем же именем (doh). Прокомментировал свойство, и миграция видит и добавляет новое поле. Переименовали собственность и все хорошо.


1

У меня была аналогичная проблема с django 3.0, согласно разделу миграции в официальной документации , запуска этого было достаточно, чтобы обновить структуру моей таблицы:

python manage.py makemigrations
python manage.py migrate

Но результат всегда был одним и тем же: «никаких изменений не обнаружено» в моих моделях после того, как я выполнил скрипт makemigrations. У меня была синтаксическая ошибка в models.py в модели, которую я хотел обновить в db:

field_model : models.CharField(max_length=255, ...)

вместо того:

field_model = models.CharField(max_length=255, ...)

Решив эту глупую ошибку, с помощью этой команды миграция прошла без проблем. Может это кому-то поможет.



0

В моем случае я забыл вставить аргументы класса

Неправильно:

class AccountInformation():

Верный

class AccountInformation(models.Model):

0

В моем случае я сначала добавил поле в модель, и Django сказал, что изменений нет.

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

В системе миграции django есть «ошибка», иногда она не видит новое поле. Может быть связано с полем даты.


0

Возможной причиной может быть удаление существующего файла db и папки миграции, вы можете использовать python, manage.py makemigrations <app_name>это должно сработать. Однажды я столкнулся с подобной проблемой.


0

Если у вас есть managed = Trueвстроенная модель Meta, вам необходимо удалить ее и выполнить миграцию. Затем снова запустите миграцию, она обнаружит новые обновления.


0

При добавлении новых моделей в приложение django api и запуске python manage.py makemigrationsинструмента никаких новых моделей не обнаружено.

Странно было то, что старые модели действительно выбирались makemigrations, но это было потому, что на них ссылались в urlpatternsцепочке, и инструмент каким-то образом их обнаруживал. Так что следите за своим поведением.

Проблема заключалась в том, что в структуре каталогов, соответствующей пакету моделей, были подпакеты, а все __init__.pyфайлы были пустыми. Они должны явно импортировать все необходимые классы в каждую подпапку и в модели, __init__.py чтобы Django мог их подобрать с помощью makemigrationsинструмента.

models
  ├── __init__.py          <--- empty
  ├── patient
     ├── __init__.py      <--- empty
     ├── breed.py
     └── ...
  ├── timeline
     ├── __init__.py      <-- empty
     ├── event.py
     └── ...

0

Попробуйте зарегистрировать свою модель в admin.py, вот пример: - admin.site.register (YourModelHere)

Вы можете сделать следующее: - 1. admin.site.register (YourModelHere) # В admin.py 2. Перезагрузить страницу и повторить попытку 3. Нажать CTRL-S и сохранить 4. Может быть ошибка, специально проверьте модели .py и admin.py 5. Или, в конце концов, просто перезапустите сервер


0

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

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

Итак, если у вас есть что-то вроде этого:

class Foobar(models.Model):
    [...]
    something = models.BooleanField(default=False)

    [...]
    def something(self):
        return [some logic]

В этом случае функция переопределит настройку выше, сделав ее «невидимой» для makemigrations.


0

Лучшее, что вы можете сделать, это удалить существующую базу данных. В моем случае я использовал базу данных phpMyAdmin SQL, поэтому я вручную удаляю созданную базу данных там.

После удаления: я создаю базу данных в PhpMyAdmin и не добавляю никаких таблиц.

Снова запустите следующие команды:

python manage.py makemigrations

python manage.py migrate

После этих команд : вы можете видеть, что django автоматически создал другие необходимые таблицы в базе данных (примерно 10 таблиц).

python manage.py makemigrations <app_name>

python manage.py migrate

И наконец: после выполнения вышеуказанных команд вся созданная вами модель (таблица) будет напрямую импортирована в базу данных.

Надеюсь, это поможет.


0

Моя проблема с этой ошибкой заключалась в том, что я включил:

class Meta:
   abstract = True

Внутренняя модель, которую я хотел создать, мигрировала.


0

У меня возникла другая проблема при создании нового приложения под названием deals. Я хотел разделить модели внутри этого приложения, поэтому у меня было 2 файла моделей с именами deals.pyи dealers.py. При работе python manage.py makemigrationsя получил: No changes detected.

Я пошел дальше и внутри, __init__.pyкоторый живет в том же каталоге, где жили мои файлы модели (сделки и дилер), я сделал

from .deals import *
from .dealers import *

И тогда makemigrationsкоманда сработала.

Оказывается, если вы никуда не импортируете модели ИЛИ имя файла ваших моделей не models.py указано, то модели не будут обнаружены.

Еще одна проблема, которая случилась со мной, - это то, как я написал приложение на settings.py :

Я имел:

apps.deals

Он должен был включать корневую папку проекта:

cars.apps.deals
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.