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, если это вообще помогает.

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

python manage.py makemigrations your_app_label

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

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

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

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

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

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

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

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

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

./manage.py makemigrations my_app

с последующим:

./manage.py migrate my_app

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

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

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

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

Это происходит при копировании и вставке файла def. из миграции, которая сама по себе определяется как массив.

Хотя, может быть, это кому-то поможет :-)

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

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

Ответ находится в этой публикации stackoverflow от cdvv7788 Migrations in Django 1.7

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

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

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

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

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

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

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

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

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

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

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

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

Вы хотите , чтобы проверить 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.
Он по-прежнему сказал: « Никаких миграций применять».

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

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

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

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

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

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

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

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

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

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

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

Удачного кодирования.

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

python manage.py migrate --fake-initial

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

В моем случае мне нужно было добавить свою модель в файл _ init _.py папки моделей, в которой была определена моя модель:

from myapp.models.mymodel import MyModel

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

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

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

Во-первых, это решение применимо к тем, кто сталкивается с той же проблемой во время развертывания на сервере heroku, я столкнулся с той же проблемой.

Для развертывания необходимо добавить django_heroku.settings (locals ()) в файл settings.py.

Изменения: когда я изменил указанную выше строку на django_heroku.settings (locals (), databases = False), она работала безупречно.

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

python manage.py makemigrations accounts Миграции для 'accounts': accounts \ migrations \ 0001_initial.py - Создать модель клиента - Создать тег модели - Создать модель продукта - Создать модель Заказ

Примечание: здесь "accounts" - это имя моего приложения