Столбец ошибок Django не существует даже после запуска миграции

Я запускаю python manage.py makemigrations и я получаю: никаких изменений не обнаружено. Затем python manage.py migrate и я получаю: никаких миграций для применения.

Затем я пытаюсь подтолкнуть изменения к производству: git push heroku master Все актуальное

Затем, в производстве, я повторяю команду: heroku run python manage.py migrate Никаких миграций для применения.

На всякий случай, я запускаю makemigrations в производстве:

heroku run python manage.py makemigrations
No changes detected

ПОЧЕМУ тогда я получаю

ProgrammingError at ....

column .... does not exist

"Без изменений" означает, что база данных согласована с кодом. Как я могу отладить это?

Ответ 1

Миграции Django записываются в вашу базу данных в таблице "django_migrations". Именно так Django знает, какие миграции были применены и которые все еще необходимо применять.

Посмотрите таблицу django_migrations в вашей БД. Возможно, что-то пошло не так, когда была применена миграция. Итак, удалите строку в таблице, в которой есть имя файла миграции, связанное с этим столбцом, который "не существует". Затем попробуйте перезапустить миграцию.

Ответ 2

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

  • Причина. Я удалил файлы миграции и заменил их одним исходным файлом миграции 0001 перед запуском миграции для последнего изменения

  • Решение:

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

И вот как решить эту проблему:

  • войти в систему как пользователь postgres (мой пользователь называется posgres):

    sudo -i -u postgres

  • Откройте терминал SQL и подключитесь к вашей базе данных:

    psql -d database_name

  • Перечислите свою таблицу и найдите таблицы, связанные с этим приложением:

    \dt

  • Отбросьте их (рассмотрите порядок удаления с отношениями):

    DROP TABLE tablename ;

  • Перечислите запись миграции, вы увидите, что примененные миграции классифицированы следующим образом:

id | app | name | applied
--+------+--------+---------+

SELECT * FROM django_migrations;
  • Удалить строки миграции этого приложения (вы можете удалить по идентификатору или по приложению, с приложением не забывайте "кавычки"):

    DELETE FROM django_migrations WHERE app='yourapp';

  • Выйдите из системы и запустите миграцию (возможно, запустите makemigrations в вашем случае):

    python manage.py migrate --settings=your.settings.module_if_any

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

Я хотел бы, чтобы это могло помочь.

Ответ 3

У меня была аналогичная проблема - сообщение об ошибке появилось, когда я нажал на модель на сайте django-admin. Я решил это, комментируя поле в models.py, а затем выполнив миграцию. После этого я расколол поле и перезапустил миграцию. После этого сообщение об ошибке исчезло.

Ответ 4

Итак, я всегда сталкиваюсь с такой проблемой, поэтому сегодня я решил попробовать и решить ее на уровне базы данных. Дело в том, что я изменил имя поля модели, которое Django не потрудилось отразить в файле миграции. Я узнал об этом позже, когда столкнулся с проблемами. Позже я посмотрел на файлы миграции и обнаружил, что для этого изменения не было никакой миграции. Но я не заметил, потому что я также внес другие изменения, поэтому, увидев файл миграции, я был счастлив. Мой совет. Создайте миграцию для каждого изменения по одному. Таким образом, вы увидите, произошло это или нет.

Итак, вот моя работа через MySQL.

откройте консоль mysql.

show databases; # see all my dbs. I deleted a few
drop database <db-name>; # if needed
use <db-name>; # the database name for your django project
show tables; # see all tables in the database
DESCRIBE <table-name>; # shows columns in the database
SHOW COLUMNS FROM <db-name>; # same thing as above
ALTER TABLE <table-name> CHANGE <old-column-name> <new-column-name> <col-type>; # now I manually updated my column name

Если вы используете postgresql, просто введите соответствующие команды в Google.

Ответ 5

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

Я вызывал функцию в одной из моих миграций, которая регулярно импортировала Модель указанной миграции, т.е.

from myApp.models import ModelX

Единственный способ импортировать модели при миграции - использовать, например, RunPython:

def myFunc(apps, schema_editor): 
    MyModel = apps.get_model('myApp 'MyModel')

и затем вызываем эту функцию следующим образом:

class Migration(migrations.Migration):
    operations = [
        migrations.RunPython(initialize_mhs, reverse_code=migrations.RunPython.noop),
    ]

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