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

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

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

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

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

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

./manage.py makemigrations <myapp>

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

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

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

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

Существует несколько возможных причин, по которым 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,

Я читал много ответов на этот вопрос, в которых часто говорилось, что нужно просто работать 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.

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

Убедитесь, что имя вашего приложения находится в 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

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

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', но также не выдает ошибку. После удаления "," все заработало, как ожидалось.

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

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

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

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

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

Я скопировал таблицу из-за пределов 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 начал принимать изменения.

1. Убедитесь, что ваше приложение упомянуто в installed_apps в settings.py
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».

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

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

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

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

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

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

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

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как описано выше.

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

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

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

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

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

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

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 или имя вашего приложения

У вас тоже может возникнуть очень глупая проблема - определить два 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")]

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

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

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.

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

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

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

У меня была аналогичная проблема с 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, ...)

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

Вы должны добавить polls.apps.PollsConfigк INSTALLED_APPSвsetting.py

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

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

class AccountInformation():

Верный

class AccountInformation(models.Model):

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

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

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

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

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

При добавлении новых моделей в приложение 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
  │   └── ...

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

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

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

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

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

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

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

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

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

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

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

python manage.py makemigrations

python manage.py migrate

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

python manage.py makemigrations <app_name>

python manage.py migrate

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

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

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

class Meta:
   abstract = True

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

У меня возникла другая проблема при создании нового приложения под названием 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