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

142

Как сказано в названии, я не могу заставить миграцию работать.

Изначально приложение было под 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, если это вообще помогает.

TyrantWave
источник
Предлагаемые решения не сработали для меня, поэтому вот мое решение, если у кого-то возникнет такая же проблема! 1. Удалите файлы миграции во всех приложениях. 2. Удалите базу данных и создайте ее заново. 3. Запустите makemigrations и выполните команды миграции PS. Сначала попробуйте шаги 1 и 3. Если ошибка не исчезла, выполните шаги 1-3.
Amoroso

Ответы:

188

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

python manage.py makemigrations your_app_label

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

Дройф
источник
1
Хороший ответ для людей, пришедших с Django 1.6! Благодарность!
Дэвид Д.
1
Что делать, если у меня больше одного приложения? Должен ли я быть python manage.py makemigrations APP_LABELдля каждого?
Alston
1
Здесь под Django 1.9 и мое приложение было создано с помощью ./manage.py startapp, но мне все равно пришлось явно упомянуть ярлык
maxbellec
50

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

  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
Мохаммед Шариф C
источник
1
Я клонировал свой проект, и папка миграции не была помещена в репо, поэтому мне пришлось добавить директора миграции, затем я добавил init .py и смог выполнить миграции. Спасибо
Джунаид
Я удалил содержимое моей папки / migrations, чтобы «сбросить» все в проекте, который я еще не развернул. Я случайно удалил __init__.pyпапку вместе с миграциями.
Сет
Это сделало это для меня .... You don't have __init__.py file inside migrations folder of those apps. (Solution: Just create an empty file with name __init__.py).. и это было вызвано добавлением файлов в.gitignore
lukik
1
Почему файл init .py так важен в папке миграции? делать миграции? Где я могу поковырять эту логику?
Nimish Bansal
1
@NimishBansal До тех пор, пока __init__.pyфайл python 3.3 не потребуется внутри каталога, чтобы он обрабатывался как пакет python. см. это
Mohammed Shareef C
30

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

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

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

TyrantWave
источник
5
Уточните, где вы изменили / добавили «managed = False»? У меня такая же проблема
Ycon
1
У меня больше нет этого кода, но я думаю, что это свойство класса, если я правильно помню.
TyrantWave
1
Хорошая точка зрения. Обратите внимание, что manage.py inspectdbдобавляет manage = False! в случае, если вы импортируете устаревшие базы данных, вы должны тщательно их настроить!
Алессандро Дентелла,
@TyrantWave, ты спас мне день. Большое спасибо.
Уткарш Шарма
убедитесь, что ваш app_labelтакой же
Luv33preet
19

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

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

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

./manage.py makemigrations my_app

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

./manage.py migrate my_app

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

Грант Игон
источник
К вашему сведению: очень важно, чтобы он сказал здесь «файлы, а также записи базы данных». Если вы удалите записи базы данных, но не сами файлы (за исключением __init.py__, это не сработает.
Майк Робинсон,
15

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

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

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

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

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

Иман Акбари
источник
1
Ваш комментарий помог мне найти мою проблему! У меня не было запятой в конце последнего варианта в списке вариантов ... очевидно, что Django очень обидчивый.
Максим
1
@Maxim: вряд ли это было причиной вашей проблемы: список без запятой в конце все равно остается списком. Другое дело - кортежи: если у вас в кортеже всего 1 элемент, вам нужна запятая после него.
blueFast
чувак, который сэкономил мне много времени! @dangonfast: в определении модели это действительно проблема.
MrE
11

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

rrrub
источник
1
Если у вас есть эта команда makemigrations, она создаст миграции для приложения. В противном случае вам потребуется запустить makemigrations app_name (которая создает этот файл)
Скотт Уоррен
7

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

jaywhy13
источник
7

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

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

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

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

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

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

MicahT
источник
7

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

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

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

Праншу Гупта
источник
6

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

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

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

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

Дениз Каплан
источник
5

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

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

Липкий
источник
5

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

пример:

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

# ... later

@property
def field(self):
    pass

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

фуринс
источник
Связанный с этим облом - иметь искаженное поле, которое все еще ускользает от проверки / проверки. Я определил hourly_rate = models.DecimalField(отсутствует завершающий '()'), и он просто потерпел неудачу.
sage
5

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

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

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

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

Джитин Павитран
источник
1
Спасибо огромное! Это помогло
Sharpless512
5

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

отметка
источник
3

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

Алекс Видис
источник
10
Никакой команды не schemamigrationсуществует - я думаю, это часть Юга? У меня сейчас вообще нет папки миграции. Удаление моего models.pyи повторный запуск inspectdb, похоже, ничего не сделали.
TyrantWave
2
schemamigrationбыл с юга. makemigrationsэто его замена.
Craig Labenz
2
Это все еще в силе. Но он изменился наmakemigrations --empty
Юлиус Курт
2

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

class Product(models.Model):
    title = models.TextField()
    description = models.TextField()
    price = models.TextField()
Сону Кумар
источник
1

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

ФибиБ
источник
1

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

RaghavHarpale
источник
1

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

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

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

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

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

отпечатки пальцев
источник
1

Может это кому-то поможет.

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

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

Себастьян Вагнер
источник
1
./manage makemigrations
./manage migrate

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

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

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

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

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

А. Х. Бенсиали
источник
1

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

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

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

from myapp.models.mymodel import MyModel
Роберт Уоллес
источник
0

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

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

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

Хаски
источник
Что ж, в django 2.0 + эта пустая строка обязательна, я считаю, мне пришлось сделать противоположное тому, что вы сделали, приятель,
Сумит Кумар Саха
@SumitKumarSaha, ха-ха, я использую в настоящее время версию Django 1.7, и эта пустая строка была причиной 2 часов попытки решить проблему миграции. Спасибо, что поделились Сумитом. Хорошего дня
Хаски
0

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

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

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

Ришаб Ахер
источник
-1

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

веб-твикеры
источник
-1

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

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

Виджай Чоудхари
источник