Si va a añadir un campo no anulable, deberá hacerlo en dos migraciones:
AddField
y RunPython
para rellenarlo
AlterField
cambiar el campo para que no sea nulo
Explaniation
En PostgreSQL y SQLite, este problema puede producirse si se dispone de un archivo RunPython
combinado con alteraciones del esquema en la misma migración. Por ejemplo, si está añadiendo un campo no anulable, los pasos de migración típicos para esto son:
AddField
para añadir el campo como anulable
RunRython
para rellenarlo
AlterField
cambiar el campo para que no sea nulo
En SQLite y Postgres, esto puede causar problemas porque todo se hace en una sola transacción.
En Documentación sobre Django tienen una advertencia específica al respecto:
En las bases de datos que sí soportan transacciones DDL (SQLite y PostgreSQL), las operaciones RunPython no tienen ninguna transacción añadida automáticamente además de las transacciones creadas para cada migración. Así, en PostgreSQL, por ejemplo, debes evitar combinar cambios de esquema y operaciones RunPython en la misma migración o puedes encontrarte con errores como OperationalError: cannot ALTER TABLE "mytable" because it has pending trigger events.
Si este es el caso, la solución es separar la migración en varias migraciones. En general, la forma de dividir es tener una primera migración que contenga los pasos hasta el comando run_python y la segunda migración que contenga todos los posteriores. Así, en el caso descrito anteriormente, el patrón sería el siguiente AddField
y RunPython
en una migración, y el AlterField
en un segundo.