Как говорится в названии, я не могу заставить миграции работать.
Первоначально приложение было под 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, если это вообще помогает.
Хорошо, похоже, я пропустил очевидный шаг, но опубликую это, если кто-то другой сделает то же самое.
При обновлении до 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_APPSmigrations в этих приложениях. (Решение: просто создайте эту папку).__init__.py в папке migrations этих приложений. (Решение: просто создайте пустой файл с именем __init__.py)__init__.py в папке приложения. (Решение: просто создайте пустой файл с именем __init__.py)models.py файла в приложенииmodels.py не наследует django.db.models.Modelmodels.pyПримечание:
Распространенной ошибкой является добавление папки migrations в файл .gitignore. При клонировании из удаленного репо папка migrations и/или файлы __init__.py будут отсутствовать в локальном репо. Это вызывает проблемы.
Я предлагаю gitignore миграционные файлы, добавив следующие строки в файл .gitignore
*/migrations/*
!*/migrations/__init__.py
Мое решение не было рассмотрено здесь, поэтому я отправляю его. Я использовал syncdb для проекта - только для его запуска и запуска. Затем, когда я попытался начать использование Django-миграций, он сначала подделывал их, а потом говорил, что это "ОК", но ничего не происходит с базой данных.
Мое решение состояло в том, чтобы просто удалить все файлы миграции для моего приложения, а также записи базы данных для миграции приложений в таблице django_migrations.
Затем я только сделал начальную миграцию с помощью:
./manage.py makemigrations my_app
а затем:
./manage.py migrate my_app
Теперь я могу выполнять миграции без проблем.
Согласитесь с @furins. Если все выглядит по порядку, и все же возникает эта проблема, проверьте, существует ли какой-либо метод свойств с тем же заголовком, что и атрибут, который вы пытаетесь добавить в класс модели.
Это довольно глупая ошибка, но с добавлением дополнительной запятой в конце строки объявления поля в классе модели делает линию недействительной.
Это происходит, когда вы копируете вставку 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 и по какой-то причине я никогда не попадал в первоначальную миграцию.
После меня работали:
Работал для меня: Python 3.4, Django 1.10
Такие люди, как я, которым не нравятся миграции, могут использовать следующие шаги.
python manage.py makemigrations app_label для начальной миграции.python manage.py migrate для создания таблиц перед внесением изменений.Если вы смутили какие-либо из этих шагов, прочитайте файлы миграции. Измените их, чтобы исправить вашу схему или удалить ненужные файлы, но не забудьте изменить следующую часть зависимостей файла миграции;)
Я надеюсь, что это поможет кому-то в будущем.
Вы хотите проверить 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 makemigrations и migrate.
Он по-прежнему сказал: никаких миграций не требуется.
Я пошел в папку migrate и открыл последний созданный файл,
комментарий миграции, которую я хотел (она была обнаружена и введена там)
и снова запустите migrate.
Это в основном редактирование файла миграции вручную.
Сделайте это, только если вы понимаете содержимое файла.
Убедитесь, что ваша модель не соответствует abstract. Я действительно совершил эту ошибку, и мне потребовалось некоторое время, поэтому я подумал, что я опубликую ее.
Использовал ли u schemamigration my_app --initial после переименования старой папки миграции? Попробуй. Может работать. Если нет - попробуйте воссоздать базу данных и сделать syncdb + migrate. Это сработало для меня...
Возникла та же проблема. Убедитесь, что все классы, которые вы определили в models.py, должны быть унаследованы от класса models.Model.
class Product(models.Model):
title = models.TextField()
description = models.TextField()
price = models.TextField()
У меня была такая же проблема, когда мне приходилось запускать 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 migratemodels.py1 и 2.models.py5.Если вы работаете с Pycharm, местная история очень полезна.
Возможно, это поможет кому-то.
Я удалил свой models.py и ожидаемый makemigrations для создания операторов DeleteModel.
Не забудьте удалить *.pyc файлы!
./manage makemigrations
./manage migrate
Миграция отслеживает изменения в БД, поэтому, если вы меняетесь с неуправляемого на управляемый, вам нужно убедиться, что таблица базы данных 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, были обнаружены!
Возможно, вам придется подделать начальные миграции с помощью команды ниже
python manage.py migrate --fake-initial
Добавление моего 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... устраняет проблему!