Django не будет применять изменения null=True к полям при запуске makemigrations и migrate

Я работаю над проектом на Django и столкнулся с проблемой: я изменил несколько полей в одной из моих моделей на значение null=True, но после запуска makemigrations и migrate изменения не отражаются в базе данных.

У меня есть модель с именем Sellers и множеством полей. Например:

class Sellers(models.Model):
...
selling_name = models.CharField(max_length=100, null=True, blank=True)
zip_code = models.IntegerField(null=True, blank=True)
...

Однако в схеме базы данных эти поля по-прежнему помечены как НЕНУЛЕВЫЕ.

Что я пробовал: Я создал пустую миграцию вручную:

python manage.py makemigrations --empty sellersapp -n fix_nullable_fields

Затем вручную добавлены операции изменения поля, такие как:

migrations.AlterField(
model_name='sellers',
name='selling_name',
field=models.CharField(max_length=100, null=True, blank=True),

),

После запуска migrate он сообщил, что миграция была применена, но по—прежнему не оказала фактического влияния на схему базы данных.

Как я могу заставить Django применить изменения null=True к существующим полям в базе данных? Есть ли правильный способ генерировать миграции, которые фактически создают соответствующие инструкции ALTER TABLE? Я знаю, что эта проблема, вероятно, связана с рассинхронизацией между схемой базы данных и состоянием миграции Django. Однако это единственное несоответствие, которое мне нужно исправить, и я считаю, что это самый чистый подход, позволяющий сделать это без перезагрузки всего.

Если есть лучший или безопасный способ синхронизировать определения полей (null=True) с фактической схемой базы данных без потери данных, я был бы очень признателен за любые предложения.

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

Итак, если поле уже было помечено как null=True при предыдущей миграции, Django предполагает, что менять нечего — даже если фактический столбец базы данных по-прежнему NOT NULL. Обычно это происходит из-за ручных изменений в базе данных, подделки или пропуска старых миграций, переключения между ветвями с разными состояниями миграции ...

Если бы я был на вашем месте, я бы заставил Django обнаружить изменение, выполнив то, что я называю фиктивной миграцией (по сути, временное изменение, чтобы "коснуться" поля):

selling_name = models.CharField(max_length=101, null=True, blank=True)
  1. Затем выполните:
python manage.py makemigrations
  1. Теперь верните полю его правильную форму:
selling_name = models.CharField(max_length=100, null=True, blank=True)
  1. Запустите makemigrations еще раз:
python manage.py makemigrations

Django сгенерирует другой AlterField, и он должен правильно включать обновление null=True.

  1. Наконец, примените перенос:
python manage.py migrate

Это все, во что я верю.

Вернуться на верх