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

теперь я могу совершать миграции без проблем.

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

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 в app
6. ваш класс Python (должен быть моделью) в models.py не наследует django.db.models.Model
7. у вас есть некоторая семантическая ошибка в определении моделей в models.py

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

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

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

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

1. удалить метод с аналогичным названием в качестве атрибута, который вы добавляете.
2. manage.py makemigrations my_app
3. manage.py миграция my_app
4. добавить методы обратно.

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

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

хотя, возможно, это поможет кому-то :-)

ответ находится на этом посте stackoverflow, cdvv7788 миграции в Django 1.7

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

manage.py makemigrations myappname как только вы это сделаете, вы можете сделать:

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

У меня была точно такая же проблема, и все вышеперечисленное отлично работало.

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

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

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

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

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

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

следующие работал для меня:

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

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

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

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

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

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

пример:

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

# ... later

@property
def field(self):
    pass

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

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

Я удалил migrations папка run makemigrations и migrate.
Он все еще говорил:--11-->нет миграции для применения.

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

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

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

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

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

недавно я обновил Django с 1.6 до 1.8 и имел несколько приложений и миграций для них. Я использовал юг и schemamigrations для создания миграций в Django 1.6, который отбрасывается в Django 1.8.

когда я добавил новые модели после обновления makemigrations команда не обнаружила никаких изменений. И тогда я попробовал решение, предложенное @drojf (1-й ответ), оно сработало нормально, но не смогло применить поддельную начальную миграцию (python manage.py --fake-initial). Я делал это, поскольку мои столы (старые столы) уже были создан.

наконец, это сработало для меня, удалило новые модели (или изменения модели) из models.py а затем пришлось удалить (или переименовать для резервного копирования безопасности) папку миграции всех приложений и запустить python manage.py makemigrations для всех приложений, затем сделал python manage.py migrate --fake-initial. Это сработало как заклинание. После того, как начальная миграция создана для всех приложений и поддельные начальной миграции, а затем добавлены новые модели и последовал регулярный процесс makemigrations и мигрировать в этом приложении. Изменения были обнаружены сейчас и все шло нормально.

Я просто подумал поделиться им здесь, Если кто-то сталкивается с той же проблемой (имея schemamigrations юга для их приложений), это может помочь им:)

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

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

я следовал этим шагам:

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

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

может быть, это поможет кому-то.

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

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

./manage makemigrations
./manage migrate

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

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

помните: если у вас есть миграция, которая заканчивается на _001 в вашей IDE & _003 в вашей базе данных. Django увидит только, если у вас есть миграция, заканчивающаяся на _004 для чего-либо обновления.

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

удачи в кодировании.

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

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

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

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

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

это оставило такую строку в последнем файле миграции:

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

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