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

Каждая миграция находится внутри транзакции. В PostgreSQL вы не должны обновлять таблицу, а затем изменять схему таблицы за одну транзакцию.

Вам необходимо разделить миграцию данных и миграцию схемы. Сначала создайте миграцию данных с помощью этого кода:

 for sender in orm['fooapp.EmailSender'].objects.filter(footer=None):
    sender.footer=''
    sender.save()

Затем создайте миграцию схемы:

manage.py schemamigration fooapp --auto

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

На операции ставлю SET CONSTRAINTS:

operations = [
    migrations.RunSQL('SET CONSTRAINTS ALL IMMEDIATE;'),
    migrations.RunPython(migration_func),
    migrations.RunSQL('SET CONSTRAINTS ALL DEFERRED;'),
]

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

1. AddField и RunPython, чтобы заполнить его
2. AlterField, чтобы изменить поле, чтобы оно не допускало значения NULL

Объяснение

В PostgreSQL и SQLite эта проблема может возникнуть, если у вас есть достаточно сложная команда RunPython в сочетании с изменениями схемы в той же миграции. Например, если вы добавляете поле, не допускающее значение NULL, типичные шаги миграции для этого следующие:

1. AddField, чтобы добавить поле как обнуляемое
2. RunRython чтобы заполнить его
3. AlterField чтобы изменить поле, чтобы оно не допускало значения NULL

В SQLite и Postgres это может вызвать проблемы, поскольку все делается за одну транзакцию.
Документы Django содержат специальное предупреждение об этом:

В базах данных, которые поддерживают транзакции DDL (SQLite и PostgreSQL), в операции RunPython не добавляются никакие транзакции, кроме транзакций, созданных для каждой миграции. Таким образом, в PostgreSQL, например, вам следует избегать объединения изменений схемы и операций RunPython в одной и той же миграции, иначе вы можете столкнуться с такими ошибками, как OperationalError: cannot ALTER TABLE mytable, потому что у него есть ожидающие события триггера.

В этом случае решение состоит в том, чтобы разделить вашу миграцию на несколько миграций. В общем, способ разделения состоит в том, чтобы иметь первую миграцию, содержащую шаги, выполняемые командой run_python, и вторую миграцию, содержащую все шаги после нее. Таким образом, в случае, описанном выше, шаблон будет AddField и RunPython в одной миграции и AlterField во второй.

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

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

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

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

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

шаг 2) затем снова сделать миграцию и мигрировать

Шаг 3) В последний раз снова добавьте поле, которое было удалено на первом шаге.

шаг 4) затем снова сделать миграцию и мигрировать

Проблема решена