Джанго - макеміграції - змін не виявлено

Я намагався створити міграцію в межах наявної програми за допомогою команди makemigrations, але вона виводить "Не виявлено змін".

Зазвичай я створюю нові програми за допомогою startappкоманди, але не використовував її для цього додатка, коли я створював її.

Після налагодження я виявив, що це не створює міграцію, оскільки migrationsпакет / папка відсутні у додатку.

Було б краще, якщо він створить папку, якщо її немає або я щось пропускаю?

Щоб створити початкові міграції програми, запустіть makemigrationsі вкажіть назву програми. Папка міграцій буде створена.

./manage.py makemigrations <myapp>

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

Моя проблема (і так її рішення) ще відрізнялася від описаної вище.

Я не використовував models.pyфайл, але створив modelsкаталог і створив my_model.pyфайл там, де я поставив свою модель. Джанго не зміг знайти мою модель, тому написав, що міграцій не потрібно застосовувати.

Моє рішення було: у my_app/models/__init__.pyфайл я додав цей рядок: from .my_model import MyModel

Існує кілька можливих причин того, що django не виявляє, що потрібно мігрувати під час makemigrationsкоманди.

1. папка міграції Вам потрібен пакет міграцій у вашому додатку.
2. INSTALLED_APPS Потрібно вказати ваш додаток у INSTALLED_APPSвироку
3. Верболісність починають із запуску makemigrations -v 3на багатослів’я. Це може пролити трохи світла на проблему.
4. Повний шлях У INSTALLED_APPSцьому розділі рекомендується вказати повний конфігураційний додаток модуля програми 'apply.apps.MyAppConfig'
5. - налаштування, яке ви хочете переконатися, що встановлено правильний файл налаштувань:manage.py makemigrations --settings mysite.settings
6. вкажіть ім'я програми, явно введіть ім'я програми manage.py makemigrations myapp- це звужує міграції лише для додатка та допоможе вам вирішити проблему.

7. мета- перевірка ви маєте право app_labelна мета-модель

8. Налагодження django налагодження основного сценарію django. Команда makemigrations в значній мірі прямо вперед. Ось як це зробити в піхармі . змінити визначення сценарію відповідним чином (наприклад: makemigrations --traceback myapp)

Кілька баз даних:

• Маршрутизатор Db при роботі з django db роутером, клас маршрутизатора (ваш власний клас маршрутизатора) повинен реалізувати allow_syncdbметод.

makemigrations завжди створює міграцію для зміни моделі, але якщо enable_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 за замовчуванням встановив "керований = помилковий". Наприклад:

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'

Змінивши керований на True, макеміграції почали збирати зміни.

1. Переконайтеся, що ваш додаток згадується у встановленому_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 Manag.py makemigrations" та "python Manag.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 Manag.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.

Bleh ... це знадобило мене так довго, щоб розібратися, і я не міг знайти рішення ніде ... Я навіть перейшов на сторінку 2 результатів google.

Сподіваюся, це допоможе комусь!

У мене була подібна проблема з 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):

У моєму випадку я спершу додав поле до моделі, і Джанго сказав, що змін немає.

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

У системі міграції джанго є "помилка", іноді вона не бачить нового поля. Може бути пов’язано з полем дати.

Можливою причиною може бути видалення існуючого db-файлу та папки міграцій. Ви можете використовувати python. manage.py makemigrations <app_name>Це повинно працювати. Я колись стикався з подібною проблемою.

Ще один крайній випадок і рішення:

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

Якщо у вас є 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)

Ви можете зробити наступне: .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. Я хотів відокремити моделі всередині цього додатка, тому у мене було два файли моделі 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