Is RemoveConstraint a reversible migration?

We’ve renamed a a model that had a constraint, and also renamed one of the fields in that constraint. The old one was something like “models.UniqueConstraint(fields=[‘driver’, ‘car’], name=‘driver_car’)” and the new is something like “models.UniqueConstraint(fields=[‘profile’, ‘car’], name=‘profile_car’)”.

I can’t get CI to work without adding a step such as RemoveConstraint(model_name=‘caruserinfo’, name=‘driver_car’), but I can’t make reverse migrations work with that step in it.

ISTM that the RemoveConstraint migration depends on model code that is now gone. I wish I’d added a field instead of renaming ‘driver’, but eventually we would have gotten to the point of deleting the old ‘driver’ field and getting to the point where reversing migrations would not have worked.

If I could add information to “RemoveConstraint” to tell it what fields it would need to use if it’s being reversed and is going to add a constraint, I would, but I don’t see how to do that.

I’d love to know if there’s something I’m missing in this picture before digging a deeper hole of some kind!

Why is this only an issue on CI? Is this not an issue with every environment that runs the code?

If a database is spun up with your migrations, the constraint on caruserinfo with the name driver_car should exist. Since your model definition has removed it, it makes sense to me that the migration system wants to generate a migration to remove that schema from your database.

As an aside, you can write your own schema modifications in SQL, then tell Django what the model representation of it is.

Mariusz posts a high level overview here: Mariusz Felisiak: "🧵 How to do blue 🔵-green 🟢 deployments with Djan…" - Fosstodon
And then there’s this part of the docs that highlights it: How to create database migrations | Django documentation | Django