Ответ 1

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

https://docs.djangoproject.com/en/1.7/topics/migrations/#adding-migrations-to-apps

"Это приведет к новой первоначальной миграции для вашего приложения. Теперь, когда вы run migrate, Django обнаружит, что у вас начальная миграция и что таблицы, которые он хочет создать, уже существуют и будут отмечать миграция уже применяется.

В противном случае вы получите ошибку отсутствия такой таблицы:)

[править] Вы очистили таблицу прикладных миграций? Это также является общей причиной не применимых миграций.

Ответ 2

• В базе данных MySQL удалите строку 'profiles' из таблицы 'django_migrations'.
• Удалить все файлы миграции в папке переноса.
• Повторите попытку python manage.py makemigrations и python manage.py migrate.

Ответ 3

Я новичок в Django, и я сталкивался с той же проблемой. Эти ответы не помогли мне. Я хотел поделиться, как я исправить проблему, возможно, это сэкономит много времени.

Ситуация:

Я вношу изменения в модель, и я хочу применить эти изменения к БД.

Что я сделал:

Выполнить на оболочке:

python manage.py makemigrations app-name
python manage.py migrate app-name

Что случилось:

• В БД не внесены изменения

• Но когда я проверяю схему db, она остается старой

Причина:

• Когда я запускаю python manage.py migrate app-name, Django проверяет таблицу django_migrations в db, чтобы увидеть, какие миграции уже применяются, и пропустит эти миграции.

То, что я пробовал:

Удалите запись с app = "my-app-name" из этой таблицы (delete from django_migrations where app = "app-name"). Очистите папку миграции и запустите python manage.py makemigration my-app-name, затем python manage.py migrate my-app-name. Это было предложено большинством голосов. Но это тоже не работает.

Зачем?

Поскольку существует существующая таблица, и то, что я создаю, было "начальной миграцией", поэтому Django решает, что начальная миграция уже применена (поскольку она видит, что таблица уже существует). Проблема в том, что существующая таблица имеет другую схему.

Решение 1:

Снимите существующую таблицу (со старой схемой), выполните первоначальные миграции и снова примените. Это будет работать (это сработало для меня), так как у нас есть "начальная миграция", и в нашем db не было таблицы с тем же именем. (Совет: я использовал python manage.py migrate my-app-name zero чтобы быстро отбросить таблицы в db)

Проблема? Возможно, вы захотите сохранить данные в существующей таблице. Вы не хотите бросать их и потерять все данные.

Решение 2:

1. Создайте начальную миграцию с той же схемой, что и существующая таблица, с помощью следующих шагов:

   • Измените ваш models.py, чтобы он соответствовал текущей таблице в вашей базе данных.

   • Удалить все файлы в "migrations"

   • Запустить python manage.py makemigrations your-app-name

2. Удалить в django_migrations все поля с django_migrations.app = your-app-name. Как это сделать, зависит от того, какой DB вы используете. Пример для MySQL: delete from django_migrations where app = "your-app-name";

3. Измените ваш models.py в соответствии с новой схемой (например, той схемой, которая вам нужна сейчас)

4. Сделайте новую миграцию, запустив python manage.py makemigrations your-app-name

5. Запустите python manage.py migrate your-app-name

Это работает для меня. И мне удалось сохранить существующие данные.

Больше мыслей:

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

Ответ 4

1- запустить python manage.py makemigrations <appname>

2- запустить python manage.py sqlmigrate <appname> <migrationname> - вы найдете имя миграции в папке переноса в appname (без расширения .py), конечно.

3- скопировать весь текст результата # все команды sql, которые сгенерировали 4- перейдите в свой db ide и вставьте в качестве нового запроса и запустите его

теперь все изменения применяются к вашему db

Ответ 5

В моем случае я написал вот так:

python manage.py makemigrations - пустой yourappname

python manage.py migrate yourappname

или

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

DELETE FROM django_migrations WHERE app=' -приложение-имя вашего '

а затем выполните:

python manage.py makemigrations python manage.py migrate

Ответ 6

python manage.py migrate --fake APPNAME zero

Это сделает вашу миграцию подделкой. Теперь вы можете запустить миграцию script

python manage.py migrate APPNAME

Таблицы будут созданы, и вы решили свою проблему.. Приветствия!

Ответ 7

Проблема здесь в фальшивых миграциях где-то. По сути, в вашей базе данных таблица, созданная на основе вашей модели, не существует, хотя где-то во времени эта таблица существовала раньше, из-за старого обновления, каким бы оно ни было. Проблема заключается в том, что django уже выполнил эти миграции, поэтому таблицы ДОЛЖНЫ существовать, следовательно, с пропуском миграций, но с ошибкой "table_doesnt_exist" в Admin.

Решение:

1.- Обязательно сохраните все данные из этой модели.

2.- Войдите в свою базу данных и выполните этот запрос.

 SELECT * FROM django_migrations;

3.- Получить идентификатор из списка, сгенерированного из запроса. Это миграции, которые Django уже перенес, поэтому ТАБЛИЦЫ ДОЛЖНЫ СУЩЕСТВОВАТЬ. В вашем случае я бы искал строку с именем roadmapprofile, потому что это имя вашей модели.

4.- Теперь давайте удалим эту строку из этой таблицы, используя идентификаторы,

 DELETE FROM django_migrations where django_migrations.id in (value_id1, value_id2 ... value_idN);

Замените value_id1 и value_id2 соответствующими идентификаторами. Это может быть только один или несколько, поэтому не беспокойтесь, если вы не видите более 1 идентификатора, это означает, что в текущем приложении существует только одна модель.

5.- Перенос приложения на ноль

 manage.py migrate <app_name> zero

6.- Удалите все файлы миграции в папке миграций приложения

7.- Создание миграций

 manage.py makemigrations

8.- После того как вы удалите эти реестры и запустите manage.py migrate; Django будет вынужден выполнить миграцию для этих моделей из-за "МИГРАЦИИ НЕ СУЩЕСТВУЮТ" для этих моделей.

 manage.py migrate

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

Ответ 8

Моя проблема заключалась в отсутствии файла __init__.py в той же папке, что и миграции. При добавлении __init__.py в папку, в которой они содержались, manage.py migrate найден и запущен.

Ответ 9

@phanhuy152 имеет лучший ответ. Просто чтобы добавить мои два цента:

Его решение:

1. Удалить историю миграции в DB
2. Удалить папку migrations
3. Отредактируйте свою модель, чтобы она соответствовала БД до изменения
4. makemigrations для восстановления исходного состояния файлов миграции
5. Затем измените модель, как вам нравится
6. makemigrations
7. migrate чтобы применить обновления к таблице.

Но в моем случае у меня есть несколько моделей в файле models.py и на последнем этапе Django жалуется на то, что Table xxx already exists, потому что исходные файлы миграции намереваются снова создать таблицу xxx, когда мы просто этого не делаем (и не хотите) отбрасывать другие таблицы.

В этом случае для того, чтобы сохранить данные, мы должны сказать, Джанго, чтобы оставить их в покое в migrate. Мы просто делаем: (предположим, что класс A является тем, который мы меняем, а класс B, C остается таким же):

models.py:

from django.db import models

class A(models.Models):
    ...

class B(models.Models):
    class Meta:
        managed = False   # tell Django to leave this class alone

    ...

class C(models.Models):
    class Meta:
        managed = False   # tell Django to leave this class alone

Добавьте эти строки после того, как мы построим начальные миграции.

Итак, теперь процесс:

1. ...
2. ...
3. ...
4. ...
5. Добавить managed = False в другие классы
6. makemigrations для применения изменений Meta. Вы увидите что-то вроде:

выход:

Migrations for 'backEnd':
  backEnd/migrations/0002_auto_20180412_1654.py
    - Change Meta options on toid
    - Change Meta options on tprocessasinc
    - Change Meta options on tservers
    - Change Meta options on tsnmpserver

7. migrate чтобы применить их в БД
8. Измените свою модель сейчас: добавьте поле, измените тип и т.д.
9. снова migrate.
10. Удалите класс Meta чтобы Django снова управлял другим классом. makemigrations, migrate снова.

Теперь у вас есть вся структура и данные ваших моделей, не теряя часть, ранее хранящуюся в БД.

Ответ 10

У меня была такая же проблема. Убедитесь, что папка миграции приложения создана (YOURAPPNAME/migrations). Удалите папку и введите команды:

python manage.py migrate --fake
python manage.py makemigrations <app_name>
python manage.py migrate --fake-initial

Я вставил эти строки в каждый класс в models.py:

class Meta:
    app_label = '<app_name>'

Это решило мою проблему.

Ответ 11

Для меня ни одно из предложенных решений не сработало. Оказывается, я использовал разные настройки для миграции (manage.py) и запуска (wsgi.py). Параметры, определенные в manage.py использовали локальную базу данных, однако в настройках wsgi.py использовалась производственная база данных. Таким образом, производственная база данных никогда не переносилась. С помощью:

django-admin migrate

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

• Убедитесь, что при миграции вы всегда используете ту же базу данных, что и при запуске !

Ответ 12

Возможно, ваша модель не связана, когда процесс миграции продолжается. Попробуйте импортировать его в файл urls.py from models import your_file