Django 1.7-makemigrations не обнаруживает изменений
как говорится в названии, я не могу заставить миграции работать.
приложение изначально было под 1.6, поэтому я понимаю, что миграции не будут там изначально, и действительно, если я запущу python manage.py migrate
Я:
Operations to perform:
Synchronize unmigrated apps: myapp
Apply all migrations: admin, contenttypes, auth, sessions
Synchronizing apps without migrations:
Creating tables...
Installing custom SQL...
Installing indexes...
Running migrations:
No migrations to apply.
если я внесу изменения в любые модели в myapp
, Она по-прежнему говорит неперенесенные, как ожидалось.
но если я сбегу python manage.py makemigrations myapp
Я:
No changes detected in app 'myapp'
не важно, что или как я запускаю команду, она никогда не обнаруживать приложения как изменения, а также добавление файлов миграции в приложение.
есть ли способ заставить приложение на миграции и по существу сказать:" Это моя база для работы " или что-нибудь еще? Или я что-то упускаю?
моя база данных является PostgreSQL, если это вообще помогает.
23 ответов
Если вы переходите от существующего приложения, которое вы сделали в django 1.6, то вам нужно сделать один предварительный шаг (как я узнал), указанный в документации:
python manage.py makemigrations your_app_label
документация не делает очевидным, что вам нужно добавить метку приложения в команду, так как первое, что она вам скажет, это python manage.py makemigrations
что не сумеет. Первоначальная миграция выполняется при создании приложения в версия 1.7, но если вы пришли из 1.6 не проводились. Вижу 'добавление миграции в приложения' в документации для более подробной информации.
Хорошо, похоже, я пропустил очевидный шаг, но разместил это на случай, если кто-то еще сделает то же самое.
при обновлении до 1.7, мои модели стали неуправляемые (managed = False
) - У меня их было как True
раньше, но, кажется, он вернулся.
удаление этой строки (по умолчанию True), а затем запуск makemigrations
сразу же сделал модуль миграции, и теперь он работает. makemigrations
не будет работать на неуправляемых таблицах (что очевидно задним числом)
мое решение не было покрыто здесь, поэтому я публикую его. Я использовал syncdb
для проекта–просто, чтобы получить его и работает. Затем, когда я попытался начать использовать миграции Django, он сначала подделал их, а затем сказал, что все в порядке, но с базой данных ничего не происходило.
мое решение было просто удалить все файлы миграции для моего приложения, а также в качестве записей базы данных для миграции приложений в django_migrations
таблица.
тогда я просто сделал начальная миграция с:
./manage.py makemigrations my_app
затем:
./manage.py migrate my_app
теперь я могу совершать миграции без проблем.
это может произойти по следующим причинам:
- вы не добавили приложение в
INSTALLED_APPS
в списокsettings.py
(Вы должны добавить название или пунктирный путь к подклассу AppConfig в apps.py в папке приложения, в зависимости от используемой версии django). См. документацию: INSTALLED_APPS - нет
migrations
внутри приложения. (Решение: просто создайте эту папку). - нет
__init__.py
внутриmigrations
папка этих приложений. (Решение: просто создайте пустой файл с именем __init__.py) - нет
__init__.py
файл внутри папки приложения. (Решение: просто создайте пустой файл с именем __init__.py) - нет
models.py
в app - ваш класс Python (должен быть моделью) в
models.py
не наследуетdjango.db.models.Model
- у вас есть некоторая семантическая ошибка в определении моделей в
models.py
Примечание:
Распространенной ошибкой является добавление на . При клонировании из удаленного РЕПО, и/или __init__.py
файлы будут отсутствовать в местных РЕПО. Это вызывает проблемы.
I предложите игнорировать файлы миграции, добавив следующие строки в
*/migrations/*
!*/migrations/__init__.py
согласен с @furins. Если все кажется в порядке, и все же эта проблема возникает, проверьте, есть ли какой-либо метод свойств с тем же заголовком, что и атрибут, который вы пытаетесь добавить в класс модели.
- удалить метод с аналогичным названием в качестве атрибута, который вы добавляете.
- manage.py makemigrations my_app
- manage.py миграция my_app
- добавить методы обратно.
Это своего рода глупая ошибка, но наличие дополнительной запятой в конце строки объявления поля в классе модели делает строку не имеющей никакого эффекта.
это происходит, когда вы копируете вставить def. из миграции, которая сама определяется как массив.
хотя, возможно, это поможет кому-то :-)
ответ находится на этом посте stackoverflow, cdvv7788 миграции в Django 1.7
Если это первый раз, когда вы обновляете это приложение, вы должны использовать:
manage.py makemigrations myappname как только вы это сделаете, вы можете сделать:
manage.py миграция если у вас есть приложение в базе данных, измените его модель и ее не обновлять изменения на makemigrations вы, наверное, нету еще не перекочевал. Измените модель на свою оригинальная форма, запустите первая команда (с именем приложения) и миграция...это будет подделка. Однажды вы делаете это, возвращаете изменения в свою модель, запускаете makemigrations и мигрируйте снова, и это должно сработать.
У меня была точно такая же проблема, и все вышеперечисленное отлично работало.
я переместил свое приложение django в cloud9, и по какой-то причине я никогда не поймал начальную миграцию.
может быть, это поможет кому-то. Я использовал вложенное приложение. проект.у нас с appname был проект и проект.appname в INSTALLED_APPS. Удаление проекта из INSTALLED_APPS позволило обнаружить изменения.
такие люди, как я, которые не любят миграции, могут использовать следующие шаги.
- удалить изменения, которые вы хотите синхронизировать.
- Run
python manage.py makemigrations app_label
для первичной миграции. - Run
python manage.py migrate
для создания таблиц перед внесением изменений. - вставить изменения, которые вы удаляете на первом шаге.
- выполнить 2. и 3. лестница.
Если вы перепутали какие-либо из этих шагов, прочитайте файлы миграции. Измените их, чтобы исправить схему или удалить нежелательные файлы, но не забудьте изменить часть зависимостей следующего файла миграции;)
Я надеюсь, это поможет кому-то в будущем.
следующие работал для меня:
- добавить имя приложения в settings.py
- использовать 'python manage.py makemigrations'
- использовать 'python manage.py migrate'
работал для меня: Python 3.4, Django 1.10
вы хотите проверить 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
юга для их приложений), это может помочь им:)
может быть, это может помочь кому-то, у меня была такая же проблема.
Я уже создал две таблицы с классом сериализатора и представлениями. Поэтому, когда я хотел обновить, у меня была эта ошибка.
я следовал этим шагам:
- я
.\manage.py makemigrations app
- выполнил
.\manage.py migrate
- я стер обе таблицы моего
models.py
- я удалил все ссылки на мои таблицы из сериализатора и класса представления.
- я выполнил шаг
1
и2
. - я восстановил свои изменения только в
models.py
- я снова выполнил шаг
5
. - я восстановил все свои изменения.
если вы работаете с 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...
строка исправлена проблема!