Opened 10 months ago

Closed 8 months ago

#23048 closed New feature (wontfix)

Add the ability to make RemoveField reversible for non-null fields

Reported by: harrislapiroff Owned by: nobody
Component: Migrations Version: 1.7-rc-1
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

RemoveField is an irreversible operation if a field's original state requires it be non-null.

To reproduce:

  • Write a model with a field with null=False
  • Make and run initial migrations.
  • Create and save some instances of your model.
  • Remove the field.
  • Make and run the migration.
  • Attempt to migrate back to the initial migration (i.e., python manage.py migrate myapp 0001)

You'll get django.db.utils.IntegrityError: myapp_mymodel__new.field may not be NULL

This behavior is documented (https://docs.djangoproject.com/en/dev/ref/migration-operations/#django.db.migrations.operations.RemoveField), but I believe there should be a way to provide a default value for the field when unapplying the migration.

Change History (3)

comment:1 Changed 10 months ago by ihulub

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

I believe there is a way to provide a default value for the field.

Have you tried passing the "default=xyz" parameter to the model field?
Example:
name = model.CharField(null=False, default="noname")

comment:2 Changed 10 months ago by timo

  • Summary changed from RemoveField irreversible in certain cases to Add the ability to make RemoveField reversible for non-null fields
  • Triage Stage changed from Unreviewed to Accepted
  • Type changed from Bug to New feature

I don't think adding a default on the model field would make any difference. Anyway, it seems like a reasonable feature request although I'm not sure how feasible it will be; tentatively accepting, although someone else can feel free to close with a rationale of why we can't do it.

comment:3 Changed 8 months ago by andrewgodwin

  • Resolution set to wontfix
  • Status changed from new to closed

Adding a default on the model field or on the field in the migration should solve this, as it'll be able to populate the new field with that when it makes it. The only other option is to prompt people for a default every time they *remove* a not null field, which really confused people in South, so let's not do that.

Closing as WONTFIX, as the solution is a simple edit to the migration.

Note: See TracTickets for help on using tickets.
Back to Top