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

Если вы переходите из существующего приложения, которое вы сделали в django 1.6, вам нужно сделать один предварительный шаг (как я узнал), перечисленные в документации:

python manage.py makemigrations your_app_label

Документация не делает очевидным, что вам нужно добавить метку приложения в команду, так как первое, что вам нужно сделать, это python manage.py makemigrations, которая не удастся. Первоначальная миграция выполняется при создании вашего приложения в версии 1.7, но если вы пришли из 1.6, это не было бы выполнено. Подробнее см. 'Добавление миграции в приложения в документации.

Мое решение не было рассмотрено здесь, поэтому я отправляю его. Я использовал 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?

После меня работали:

• Добавить имя приложения в 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. шаги.

Если вы смутили какие-либо из этих шагов, прочитайте файлы миграции. Измените их, чтобы исправить вашу схему или удалить ненужные файлы, но не забудьте изменить следующую часть зависимостей файла миграции;)

Я надеюсь, что это поможет кому-то в будущем.

Ответ на этот пост stackoverflow, cdvv7788 Миграции в Django 1.7

Если вы в первый раз переносите это приложение, вы должны использовать:

manage.py makemigations myappname После этого вы можете сделать:

manage.py migrate Если у вас есть приложение в базе данных, измените его модель и он не обновляет изменения в макэмиграции, которые вы, вероятно, не имеете еще мигрировала. Измените модель на первоначальную форму, запустите первая команда (с именем приложения) и мигрировать... она подделает ее. однажды вы делаете это, чтобы вернуть изменения в вашей модели, запустить makemigrations и мигрировать снова, и он должен работать.

У меня была такая же проблема, и работа над ней работала отлично.

Я переместил приложение django в cloud9 и по какой-то причине я никогда не попадал в первоначальную миграцию.

Может быть, это поможет кому-то. Я использовал вложенное приложение. project.appname, и у меня на самом деле был проект и project.appname в INSTALLED_APPS. Удаление проекта из INSTALLED_APPS позволило обнаружить изменения.

Вы хотите проверить settings.py в списке INSTALLED_APPS и убедиться, что все приложения с моделями указаны там.

Запуск makemigrations в папке проекта означает, что он будет обновлять все таблицы, связанные со всеми приложениями, включенными в settings.py для проекта. После того, как вы включите его, makemigrations будет автоматически включать приложение (это экономит много работы, поэтому вам не нужно запускать makemigrations app_name для каждого приложения в вашем проекте/сайте).

Добавление этого ответа, потому что только этот метод помог мне.

Я удалил папку migrations makemigrations и migrate.
Он по-прежнему сказал: никаких миграций не требуется.

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

Это в основном редактирование файла миграции вручную.
Сделайте это, только если вы понимаете содержимое файла.

На всякий случай у вас есть определенное поле, которое не идентифицируется с помощью makemigrations: дважды проверьте, если у вас есть свойство с тем же именем.

Пример:

field = django.db.models.CharField(max_length=10, default = '', blank=True, null=True)

# ... later

@property
def field(self):
    pass

свойство будет "перезаписывать" определение поля, поэтому изменения не будут идентифицироваться с помощью makemigrations

Это может произойти по следующим причинам:

• Вы не добавили приложение в список 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

Убедитесь, что ваша модель не соответствует abstract. Я действительно совершил эту ошибку, и мне потребовалось некоторое время, поэтому я подумал, что я опубликую ее.

Использовал ли u schemamigration my_app --initial после переименования старой папки миграции? Попробуй. Может работать. Если нет - попробуйте воссоздать базу данных и сделать syncdb + migrate. Это сработало для меня...

./manage makemigrations
./manage migrate

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

Если вы все еще находитесь в режиме dev, я лично решил удалить файлы миграции в своей среде IDE, а также в таблице django_migrations, относящейся к моей модели, и повторить указанную выше команду.

ПОМНИТЕ: если у вас есть миграция, которая заканчивается на _001 в вашей среде IDE и _003 в вашей базе данных. Django увидит только, закончится ли переход на _004 для обновления.

2 (миграция кода и db) связаны и работают в тандеме.

Счастливое кодирование.

Возможно, это поможет кому-то.

Я удалил свой models.py и ожидаемый makemigrations для создания операторов DeleteModel.

Не забудьте удалить *.pyc файлы!

Может быть, это может помочь кому-то, у меня была та же проблема.

Я уже создал две таблицы с классом сериализатора и представлениями. Поэтому, когда я хотел обновить, у меня была эта ошибка.

Я выполнил следующие шаги:

• Я сделал .\manage.py makemigrations app
• Я выполнил .\manage.py migrate
• Я удалил обе таблицы моего models.py
• Я удалил все ссылки на мои таблицы из сериализатора и класса вида.
• Я выполнил шаги 1 и 2.
• Я получил мои изменения только в models.py
• Я снова выполнил шаг 5.
• Я восстановил все свои изменения.

Если вы работаете с Pycharm, местная история очень полезна.

Недавно я обновил 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 юга для своих приложений), это может помочь им:)

У меня была такая же проблема, когда мне приходилось запускать makemigrations дважды и всевозможные странные действия. Оказалось, что корень проблемы состоял в том, что я использовал функцию для установки дат по умолчанию в своих моделях, поэтому миграция обнаруживала изменения каждый раз, когда я запускал makemigrations. Ответ на этот вопрос поставил меня на правильный путь: Избегайте повторного создания поля даты

Добавление моего 2c, поскольку ни один из этих решений не работал у меня, но это произошло...

Я только что запустил manage.py squashmigrations и удалил старые миграции (как файлы, так и строки в таблице базы данных django.migrations).

В последнем файле миграции осталась такая строка:

replaces = [(b'my_app', '0006_auto_20170713_1735'), (b'my_app', '0007_auto_20170713_2003'), (b'my_app', '0008_auto_20170713_2004')]

Это, по-видимому, запутало Django и вызвало странное поведение: запуск manage.py makemigrations my_app воссоздал первоначальную миграцию, как будто никого не было. Удаление строки replaces... устраняет проблему!