Django 1.7 – makemigrations не обнаруживает изменений
Как говорится в названии, я не могу заставить миграции работать.
Первоначально приложение было под 1,6, поэтому я понимаю, что миграций там не будет, и если я запустил python manage.py migrate , я получаю:
Если я вношу изменения в любые модели в myapp , он все равно говорит о немиграции, как и ожидалось.
Но если я запустил python manage.py makemigrations myapp , я получаю:
Не похоже, что и как я запускаю команду, она никогда не обнаруживает, что приложение имеет изменения, и не добавляет никаких файлов миграции в приложение.
Есть ли способ заставить приложение перейти на миграцию и по существу сказать: “Это моя база для работы” или что-то еще? Или я что-то упускаю?
Моя база данных является PostgreSQL, если это вообще помогает.
Хорошо, похоже, я пропустил очевидный шаг, но опубликую это, если кто-то другой сделает то же самое.
При обновлении до 1.7 мои модели стали неуправляемыми ( managed = False ) – раньше я их использовал как True , но, похоже, он вернулся.
Удаление этой строки (по умолчанию True), а затем запуск makemigrations сразу же создал модуль миграции и теперь он работает. makemigrations не будет работать на неуправляемых таблицах (что очевидно в ретроспективе)
Если вы переходите из существующего приложения, которое вы сделали в django 1.6, вам нужно сделать один предварительный шаг (как я узнал), перечисленные в документации:
python manage.py makemigrations your_app_label
Документация не делает очевидным, что вам нужно добавить метку приложения в команду, так как первое, что вам нужно сделать, это python manage.py makemigrations , которая не удастся. Первоначальная миграция выполняется при создании вашего приложения в версии 1.7, но если вы пришли из 1.6, это не было бы выполнено. Подробнее см. ‘Добавление миграции в приложения в документации.
Это может произойти по следующим причинам:
- Вы не добавили приложение в список INSTALLED_APPS в settings.py
(Вы должны добавить либо имя приложения, либо пунктирный путь к подклассу AppConfig в файле apps.py в папке приложения, в зависимости от используемой версии django). См. документацию: INSTALLED_APPS - У вас нет папки migrations в этих приложениях. (Решение: просто создайте эту папку).
- У вас нет файла __init__.py в папке migrations этих приложений. (Решение: просто создайте пустой файл с именем __init__.py)
- У вас нет файла __init__.py в папке приложения. (Решение: просто создайте пустой файл с именем __init__.py)
- У вас нет models.py файла в приложении
- Ваш класс Python (должен быть моделью) в models.py не наследует django.db.models.Model
- У вас есть некоторая семантическая ошибка в определении моделей в models.py
Примечание:
Распространенной ошибкой является добавление папки migrations в файл .gitignore . При клонировании из удаленного репо папка migrations и/или файлы __init__.py будут отсутствовать в локальном репо. Это вызывает проблемы.
Я предлагаю gitignore миграционные файлы, добавив следующие строки в файл .gitignore
Мое решение не было рассмотрено здесь, поэтому я отправляю его. Я использовал syncdb для проекта – только для его запуска и запуска. Затем, когда я попытался начать использование Django-миграций, он сначала подделывал их, а потом говорил, что это “ОК”, но ничего не происходит с базой данных.
Мое решение состояло в том, чтобы просто удалить все файлы миграции для моего приложения, а также записи базы данных для миграции приложений в таблице django_migrations .
Затем я только сделал начальную миграцию с помощью:
./manage.py makemigrations my_app
./manage.py migrate my_app
Теперь я могу выполнять миграции без проблем.
Согласитесь с @furins. Если все выглядит по порядку, и все же возникает эта проблема, проверьте, существует ли какой-либо метод свойств с тем же заголовком, что и атрибут, который вы пытаетесь добавить в класс модели.
- Удалить метод с похожим именем как добавляемый атрибут.
- manage.py makemigrations my_app
- manage.py migrate my_app
- Добавьте методы назад.
Это довольно глупая ошибка, но с добавлением дополнительной запятой в конце строки объявления поля в классе модели делает линию недействительной.
Это происходит, когда вы копируете вставку def. из миграции, которая сама определяется как массив.
Хотя, возможно, это помогло бы кому-то: -)
Может быть, я опоздал, но вы пытались добавить в свое приложение папку migrations с файлом __init__.py ?
Может быть, это поможет кому-то. Я использовал вложенное приложение. project.appname, и у меня на самом деле был проект и project.appname в INSTALLED_APPS. Удаление проекта из INSTALLED_APPS позволило обнаружить изменения.
Ответ на этот пост stackoverflow, cdvv7788 Миграции в Django 1.7
Если вы в первый раз переносите это приложение, вы должны использовать:
manage.py makemigations myappname После этого вы можете сделать:
manage.py migrate Если у вас есть приложение в базе данных, измените его модель и он не обновляет изменения в макэмиграции, которые вы, вероятно, не имеете еще мигрировала. Измените модель на первоначальную форму, запустите первая команда (с именем приложения) и мигрировать… она подделает ее. однажды вы делаете это, чтобы вернуть изменения в вашей модели, запустить makemigrations и мигрировать снова, и он должен работать.
У меня была такая же проблема, и работа над ней работала отлично.
Я переместил приложение django в cloud9 и по какой-то причине я никогда не попадал в первоначальную миграцию.
После меня работали:
- Добавить имя приложения в settings.py
- использовать ‘python manage.py makemigrations’
- использовать ‘python manage.py migrate’
Работал для меня: Python 3.4, Django 1.10
Такие люди, как я, которым не нравятся миграции, могут использовать следующие шаги.
- Удалите изменения, которые вы хотите синхронизировать.
- Запустите python manage.py makemigrations app_label для начальной миграции.
- Запустите python manage.py migrate для создания таблиц перед внесением изменений.
- Вставить изменения, которые вы удаляете с первого шага.
- Запустите 2. и 3. шаги.
Если вы смутили какие-либо из этих шагов, прочитайте файлы миграции. Измените их, чтобы исправить вашу схему или удалить ненужные файлы, но не забудьте изменить следующую часть зависимостей файла миграции;)
Я надеюсь, что это поможет кому-то в будущем.
Вы хотите проверить settings.py в списке INSTALLED_APPS и убедиться, что все приложения с моделями указаны там.
Запуск makemigrations в папке проекта означает, что он будет обновлять все таблицы, связанные со всеми приложениями, включенными в settings.py для проекта. После того, как вы включите его, makemigrations будет автоматически включать приложение (это экономит много работы, поэтому вам не нужно запускать makemigrations app_name для каждого приложения в вашем проекте/сайте).
На всякий случай у вас есть определенное поле, которое не идентифицируется с помощью makemigrations: дважды проверьте, если у вас есть свойство с тем же именем.
свойство будет “перезаписывать” определение поля, поэтому изменения не будут идентифицироваться с помощью makemigrations
Добавление этого ответа, потому что только этот метод помог мне.
Я удалил папку migrations makemigrations и migrate .
Он по-прежнему сказал: никаких миграций не требуется.
Я пошел в папку migrate и открыл последний созданный файл,
комментарий миграции, которую я хотел (она была обнаружена и введена там)
и снова запустите migrate .
Это в основном редактирование файла миграции вручную.
Сделайте это, только если вы понимаете содержимое файла.
Убедитесь, что ваша модель не соответствует abstract . Я действительно совершил эту ошибку, и мне потребовалось некоторое время, поэтому я подумал, что я опубликую ее.
Использовал ли u schemamigration my_app —initial после переименования старой папки миграции? Попробуй. Может работать. Если нет – попробуйте воссоздать базу данных и сделать syncdb + migrate. Это сработало для меня…
Возникла та же проблема. Убедитесь, что все классы, которые вы определили в models.py, должны быть унаследованы от класса models.Model.
У меня была такая же проблема, когда мне приходилось запускать makemigrations дважды и всевозможные странные действия. Оказалось, что корень проблемы состоял в том, что я использовал функцию для установки дат по умолчанию в своих моделях, поэтому миграция обнаруживала изменения каждый раз, когда я запускал makemigrations. Ответ на этот вопрос поставил меня на правильный путь: Избегайте повторного создания поля даты
Недавно я обновил Django с 1,6 до 1,8 и для них было мало приложений и миграций. Я использовал юг и schemamigrations для создания миграции в Django 1.6, который был опущен в Django 1.8.
Когда я добавил новые модели после обновления, команда makemigrations не обнаружила никаких изменений. И затем я попробовал решение, предложенное @drojf (1-й ответ), он работал нормально, но не смог применить фальшивую начальную миграцию ( python manage.py —fake-initial ). Я делал это, так как мои таблицы (старые таблицы) уже были созданы.
Наконец, это сработало для меня, удалило новые модели (или изменения модели) с models.py, а затем пришлось удалить (или переименовать для безопасного резервного копирования) папку миграций всех приложений и запустить mathemigations для python manage.py для всех приложений, затем сделал python manage.py migrate —fake-initial . Это работало как прелесть. Когда начальная миграция создается для всех приложений и поддельная начальная миграция, добавлены новые модели и выполняются регулярные процессы makemigrations и переносятся на это приложение. Изменения были обнаружены сейчас, и все прошло хорошо.
Я просто подумал о том, чтобы поделиться им здесь, если кто-то сталкивается с такой же проблемой (имея schemamigrations юга для своих приложений), это может помочь им:)
Может быть, это может помочь кому-то, у меня была та же проблема.
Я уже создал две таблицы с классом сериализатора и представлениями.
Поэтому, когда я хотел обновить, у меня была эта ошибка.
Я выполнил следующие шаги:
- Я сделал .\manage.py makemigrations app
- Я выполнил .\manage.py migrate
- Я удалил обе таблицы моего models.py
- Я удалил все ссылки на мои таблицы из сериализатора и класса вида.
- Я выполнил шаги 1 и 2 .
- Я получил мои изменения только в models.py
- Я снова выполнил шаг 5 .
- Я восстановил все свои изменения.
Если вы работаете с Pycharm, местная история очень полезна.
Возможно, это поможет кому-то.
Я удалил свой models.py и ожидаемый makemigrations для создания операторов DeleteModel .
Не забудьте удалить *.pyc файлы!
Миграция отслеживает изменения в БД, поэтому, если вы меняетесь с неуправляемого на управляемый, вам нужно убедиться, что таблица базы данных youre актуальна в отношении модели, с которой вы имеете дело.
Если вы все еще находитесь в режиме dev, я лично решил удалить файлы миграции в своей среде IDE, а также в таблице django_migrations, относящейся к моей модели, и повторить указанную выше команду.
ПОМНИТЕ: если у вас есть миграция, которая заканчивается на _001 в вашей среде IDE и _003 в вашей базе данных. Django увидит только, закончится ли переход на _004 для обновления.
2 (миграция кода и db) связаны и работают в тандеме.
Добавил этот ответ, потому что ни один из других доступных выше не работал для меня.
В моем случае происходило что-то еще более странное (версия Django 1.7). В моем models.py у меня была “лишняя” строка в конце моего файла (это была пустая строка), и когда я выполнял python manage.py makemigrations Команда результат был: “Изменения не обнаружены”.
Чтобы исправить это, я удалил эту “пустую строку”, которая была в конце моего файла models.py, и снова запустил команду, все было исправлено, и все изменения, сделанные в models.py, были обнаружены!
Возможно, вам придется подделать начальные миграции с помощью команды ниже
Добавление моего 2c, поскольку ни один из этих решений не работал у меня, но это произошло…
Я только что запустил manage.py squashmigrations и удалил старые миграции (как файлы, так и строки в таблице базы данных django.migrations).
В последнем файле миграции осталась такая строка:
Источник
Django — makemigrations — Изменения не обнаружены
Я пытался создать миграции в существующем приложении с помощью команды makemigrations, но она выдает «Изменения не обнаружены».
Обычно я создаю новые приложения с помощью команды startapp , но не использую их для этого приложения при создании.
После отладки я обнаружил, что он не создает миграцию, поскольку в приложении отсутствует пакет / папка migrations .
Будет ли лучше, если он создаст папку, если ее там нет или я что-то упустил?
19 ответов
Чтобы создать начальные миграции для приложения, запустите makemigrations и укажите имя приложения. Папка миграций будет создана.
Ваше приложение должно быть сначала включено в INSTALLED_APPS (внутри settings.py).
Очень глупая проблема, с которой вы можете столкнуться — это определить два class Meta в вашей модели. В этом случае любое изменение первого не будет применено при выполнении makemigrations .
Иногда ./manage.py makemigrations превосходит ./manage.py makemigrations , потому что он может обрабатывать определенные конфликты между приложениями.
Эти случаи происходят незаметно, и swearing требуется несколько часов, чтобы понять реальный смысл страшного No changes detected сообщения.
Следовательно, гораздо лучше использовать следующую команду:
Я прочитал много ответов на этот вопрос, часто заявляя, что нужно просто запустить makemigrations другими способами. Но для меня проблема заключалась в подклассе моделей Meta .
Запуск Джанго 1.10 здесь.
Моя проблема (и, таким образом, решение) все же отличалась от описанной выше.
Я не использовал файл models.py , но создал каталог models и создал файл my_model.py там, куда я поместил свою модель. Django не смог найти мою модель, поэтому он написал, что нет миграций для применения.
Мое решение было: в файле my_app/models/__init__.py я добавил эту строку: < < Х1 >>
Это комментарий, но, вероятно, должен быть ответ.
Убедитесь, что имя вашего приложения находится в settings.py INSTALLED_APPS , в противном случае, независимо от того, что вы делаете, оно не запустит миграцию.
Я знаю, что это старый вопрос, но я боролся с этой же проблемой весь день, и мое решение было простым.
У меня была структура каталогов что-то вроде .
И поскольку все другие модели, вплоть до той, с которой у меня возникла проблема, импортировались в другое место, которое в итоге импортировалось из main_app , который был зарегистрирован в INSTALLED_APPS , мне просто повезло, что все они работали.
Но так как я только добавил каждый app в INSTALLED_APPS , а не app_sub* , когда я наконец добавил новый файл моделей, который больше нигде не был импортирован, Django полностью проигнорировал его.
Мое исправление заключалось в добавлении файла models.py в базовый каталог каждого app следующим образом .
А затем добавьте from apps.app.app_sub1 import * и т. д. в каждый из файлов app уровня models.py .
Bleh . это заняло у меня так много времени, чтобы выяснить, и я не мог найти решение нигде . Я даже пошел на страницу 2 результатов Google.
Надеюсь, это кому-то поможет!
Я скопировал таблицу из-за пределов django, и класс Meta по умолчанию установил «managed = false». Например:
Изменив значение «Успешно» на «Истина», makemigrations начали собирать изменения.
Решение заключается в том, что вы должны включить свое приложение в INSTALLED_APPS.
Я пропустил это, и я нашел эту же проблему.
После указания моего имени приложения миграция стала успешной
Пожалуйста, обратите внимание, что я упомянул доски в прошлом, это название моего приложения.
Моя проблема была намного проще, чем приведенные выше ответы, и, вероятно, гораздо более распространенная причина, если ваш проект уже настроен и работает. В одном из моих приложений, которые работали в течение долгого времени, миграции казались неудачными, поэтому я торопливо сделал следующее:
Я также по ошибке удалил все файлы __init__.py 🙁 — После того, как я вошел, все снова заработало и:
Тогда для каждого из моих приложений makemigrations снова работал.
Оказывается, я вручную создал новое приложение, скопировав другое, и забыл поместить __init__.py в папку migrations , и это убедило меня в том, что все шатко, что привело к ухудшению моего состояния с << X2>> как описано выше.
Надеюсь, что это поможет кому-то в течение нескольких часов ругаться с ошибкой «Изменения не обнаружены».
Прежде всего, убедитесь, что ваше приложение зарегистрировано в Installed_app в файле setting.py. Тогда приведенный выше ответ работает отлично
В моем случае я забыл вставить аргументы класса
Источник