Django - makemigrations - Изменения не обнаружены
Я пытался создать миграции в существующем приложении с помощью команды makemigrations, но она выдает "Изменения не обнаружены".
Обычно я создаю новые приложения с помощью команды startapp
но не использую их для этого приложения при создании.
После отладки я обнаружил, что он не создает миграцию, поскольку пакет/папка migrations
отсутствует в приложении.
Будет ли лучше, если он создаст папку, если ее там нет или я что-то упустил?
Ответы
Ответ 1
Чтобы создать начальные миграции для приложения, запустите makemigrations
и укажите имя приложения. Папка миграций будет создана.
./manage.py makemigrations <myapp>
Ваше приложение должно быть сначала включено в INSTALLED_APPS
(внутри settings.py).
Ответ 2
Моя проблема (и, следовательно, решение) все еще отличалась от описанной выше.
Я не использовал файл models.py
, но создал каталог models
и создал там файл my_model.py
, где я поместил свою модель. Django не смог найти мою модель, поэтому он написал, что миграций не требуется.
Мое решение было: в файле my_app/models/__init__.py
я добавил эту строку:
from .my_model import MyModel
Ответ 3
Существует несколько возможных причин, по которым django не обнаруживает, что нужно переносить во время команды makemigrations
.
- папка переноса. В приложении требуется пакет миграции.
- INSTALLED_APPS. Ваше приложение должно быть указано в
INSTALLED_APPS
.dict - Многословие начинается с запуска
makemigrations -v 3
для многословия. Это может пролить свет на проблему. - Полный путь В
INSTALLED_APPS
рекомендуется указать полный путь конфигурации приложения к модулю 'apply.apps.MyAppConfig' - --settings вы можете убедиться, что установлен правильный файл настроек:
manage.py makemigrations --settings mysite.settings
- указать имя приложения явно помещать имя приложения в
manage.py makemigrations myapp
- это сужает миграцию только для приложения и помогает вам изолировать проблему. -
meta проверить, что у вас есть подходящая app_label
в вашей метатеге модели
-
Debug django отлаживает основной скрипт django. Команда makemigrations довольно прямолинейна. Вот как это сделать в pycharm. измените определение своего сценария соответственно (например: makemigrations --traceback myapp
)
Несколько баз данных:
- Db Router при работе с маршрутизатором django db класс маршрутизатора (ваш собственный класс маршрутизатора) должен реализовать метод
allow_syncdb
.
makemigrations всегда создает миграции для изменений модели, но если allow_migrate() возвращает False,
Ответ 4
Я читал много ответов на этот вопрос, часто заявляя, что просто запускаю makemigrations
другими способами. Но для меня проблема была в Meta
подклассе моделей.
У меня есть app config, который говорит 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 здесь.
Ответ 5
Это комментарий, но, вероятно, должен быть ответом.
Убедитесь, что ваше имя приложения находится в 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
Ответ 6
Иногда, когда ./manage.py makemigrations
превосходит ./manage.py makemigrations <myapp>
, потому что он может обрабатывать определенные конфликты между приложениями.
Эти случаи происходят беззвучно, и для понимания реального значения ужасного сообщения No changes detected
требуется несколько часов swearing
.
Поэтому лучше использовать следующую команду:
./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 начали собирать изменения.
Ответ 8
У меня была еще одна проблема, не описанная здесь, и это заставило меня замочить.
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", но также не выдала ошибку. После удаления "," он работал, как ожидалось.
Поэтому будьте осторожны, когда вы копируете и вставляете :-)
Ответ 9
Я решил эту проблему, выполнив следующие действия:
- Удалите файл "db.sqlite3". Проблема здесь в том, что ваша текущая база данных будет стерта, поэтому вам придется переделать ее снова.
- Внутри папки миграции вашего отредактированного приложения удалите последний обновленный файл. Помните, что первый созданный файл: "0001_initial.py". Например: я создал новый класс и зарегистрировал его с помощью процедуры "makemigrations" и "migrate", теперь был создан новый файл с названием "0002_auto_etc.py"; стереть его.
- Перейдите в папку "pycache" (внутри папки миграции) и удалите файл "0002_auto_etc.pyc".
- Наконец, перейдите на консоль и используйте "python manage.py makemigrations" и "python manage.py migrate".
Ответ 10
Решение заключается в том, что вы должны включить свое приложение в INSTALLED_APPS.
Я пропустил это, и я нашел эту проблему.
после того, как мое имя приложения изменилось, стало успешным
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'boards',
]
обратите внимание, что я упоминал доски в последнем, это мое имя приложения.
Ответ 11
Очень глупая проблема, с которой вы можете столкнуться - это определить два 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")]
Ответ 12
Я знаю, что это старый вопрос, но я боролся с этой же проблемой весь день, и мое решение было простым.
У меня была структура каталогов что-то вроде...
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.
Надеюсь, это поможет кому-то!
Ответ 13
Вы должны добавить polls.apps.PollsConfig
в INSTALLED_APPS
в setting.py
Ответ 14
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 или название вашего приложения
Ответ 15
Для Django 3.0 я следую учебнику из https://www.youtube.com/watch?v=F5mRW0jo-U4&t=2475s, и я также столкнулся с тем же. Никаких изменений не обнаружено при моем первом редактировании файла model.py.
Я видел другие учебные пособия (https://docs.djangoproject.com/en/2.2/intro/tutorial02/), которые включают models.Model в качестве параметра класса:
До: класс продуктов():
Сейчас: класс товаров (модели. Модель):
и команда makemigrations сработала:
Миграции для "продуктов":
продукты\миграции\0001_initial.py
- Создание модельных продуктов
Ответ 16
- Убедитесь, что ваше приложение упомянуто в instal_apps в settings.py
- Убедитесь, что ваш модельный класс расширяет модели. Модель
Ответ 17
Прежде всего, убедитесь, что ваше приложение зарегистрировано в Installed_app в файле setting.py.
Тогда приведенный выше ответ работает отлично
Ответ 18
Я забыл поставить правильные аргументы:
class LineInOffice(models.Model): # here
addressOfOffice = models.CharField("Корхоная жош",max_length= 200) #and here
...
в models.py
а затем он начал отбрасывать это раздражает
В приложении myApp не обнаружено изменений