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

Ответ 1

Хорошо, похоже, я пропустил очевидный шаг, но опубликую это, если кто-то другой сделает то же самое.

При обновлении до 1.7 мои модели стали неуправляемыми (managed = False) - раньше я их использовал как True, но, похоже, он вернулся.

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

Ответ 2

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

python manage.py makemigrations your_app_label

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

Ответ 3

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

1. Вы не добавили приложение в список INSTALLED_APPS в settings.py (Вы должны добавить либо имя приложения, либо пунктирный путь к подклассу AppConfig в файле apps.py в папке приложения, в зависимости от используемой версии django). См. документацию: INSTALLED_APPS
2. У вас нет папки migrations в этих приложениях. (Решение: просто создайте эту папку).
3. У вас нет файла __init__.py в папке migrations этих приложений. (Решение: просто создайте пустой файл с именем __init__.py)
4. У вас нет файла __init__.py в папке приложения. (Решение: просто создайте пустой файл с именем __init__.py)
5. У вас нет models.py файла в приложении
6. Ваш класс Python (должен быть моделью) в models.py не наследует django.db.models.Model
7. У вас есть некоторая семантическая ошибка в определении моделей в models.py

Примечание: Распространенной ошибкой является добавление папки migrations в файл .gitignore. При клонировании из удаленного репо папка migrations и/или файлы __init__.py будут отсутствовать в локальном репо. Это вызывает проблемы.

Я предлагаю gitignore миграционные файлы, добавив следующие строки в файл .gitignore

*/migrations/*
!*/migrations/__init__.py

Ответ 4

Мое решение не было рассмотрено здесь, поэтому я отправляю его. Я использовал syncdb для проекта - только для его запуска и запуска. Затем, когда я попытался начать использование Django-миграций, он сначала подделывал их, а потом говорил, что это "ОК", но ничего не происходит с базой данных.

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

Затем я только сделал начальную миграцию с помощью:

./manage.py makemigrations my_app

а затем:

./manage.py migrate my_app

Теперь я могу выполнять миграции без проблем.

Ответ 5

Согласитесь с @furins. Если все выглядит по порядку, и все же возникает эта проблема, проверьте, существует ли какой-либо метод свойств с тем же заголовком, что и атрибут, который вы пытаетесь добавить в класс модели.

• Удалить метод с похожим именем как добавляемый атрибут.
• manage.py makemigrations my_app
• manage.py migrate my_app
• Добавьте методы назад.

Ответ 6

Это довольно глупая ошибка, но с добавлением дополнительной запятой в конце строки объявления поля в классе модели делает линию недействительной.

Это происходит, когда вы копируете вставку def. из миграции, которая сама определяется как массив.

Хотя, возможно, это помогло бы кому-то: -)

Ответ 7

Может быть, я опоздал, но вы пытались добавить в свое приложение папку migrations с файлом __init__.py?

Ответ 8

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

Ответ 9

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

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

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

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

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

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

Ответ 10

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

• Добавить имя приложения в settings.py
• использовать 'python manage.py makemigrations'
• использовать 'python manage.py migrate'

Работал для меня: Python 3.4, Django 1.10

Ответ 11

Такие люди, как я, которым не нравятся миграции, могут использовать следующие шаги.

• Удалите изменения, которые вы хотите синхронизировать.
• Запустите python manage.py makemigrations app_label для начальной миграции.
• Запустите python manage.py migrate для создания таблиц перед внесением изменений.
• Вставить изменения, которые вы удаляете с первого шага.
• Запустите 2. и 3. шаги.

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

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

Ответ 12

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

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

Ответ 13

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

Пример:

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

# ... later

@property
def field(self):
    pass

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

Ответ 14

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

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

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

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

Ответ 15

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

Ответ 16

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

Ответ 17

Возникла та же проблема. Убедитесь, что все классы, которые вы определили в models.py, должны быть унаследованы от класса models.Model.

class Product(models.Model):
    title = models.TextField()
    description = models.TextField()
    price = models.TextField()

Ответ 18

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

Ответ 19

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

Ответ 20

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

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

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

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

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

Ответ 21

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

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

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

Ответ 22

./manage makemigrations
./manage migrate

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

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

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

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

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

Ответ 23

Добавил этот ответ, потому что ни один из других доступных выше не работал для меня.

В моем случае происходило что-то еще более странное (версия Django 1.7). В моем models.py у меня была "лишняя" строка в конце моего файла (это была пустая строка), и когда я выполнял python manage.py makemigrations Команда результат был: "Изменения не обнаружены".

Чтобы исправить это, я удалил эту "пустую строку", которая была в конце моего файла models.py, и снова запустил команду, все было исправлено, и все изменения, сделанные в models.py, были обнаружены!

Ответ 24

Возможно, вам придется подделать начальные миграции с помощью команды ниже

python manage.py migrate --fake-initial

Ответ 25

Добавление моего 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... устраняет проблему!