Changing options for STATUS is not triggering new db migrations like desired

Given that behind the scenes we are having syntax sugar for a CharField with some fixed choices, I was expecting the same behavior, which is: any change on the choices tuple causes a new migration.

Having a model like this:

class Article(StatusModel):
    STATUS = Choices('draft', 'published')

if I later modify it like this,

class Article(StatusModel):
    STATUS = Choices('draft', 'published', 'finished')

manage.py makemigrations reports No changes detected

However, if the new option added is the first one, like here

class Article(StatusModel):
    STATUS = Choices('predraft', 'draft', 'published')

manage.py makemigrations creates a new migration

[romgar]

Hi @jmansilla !

I guess the answer is related to this part of the documentation: [...] sets its default value to the first item in the STATUS choices.

That explains the different behaviors you encountered. In the first situation, you add a value at the end, which doesn’t impact the default value of the StatusField.

But when you add a new value at the beginning, this changes the default value from your StatusField, which Django detects to trigger a new migration.

If you don’t want this behavior, fixing a default value for your StatusField would solve your issue, as you will then be insensitive to your choice list ordering.

I’m not a great fan of hidden logic like “the first one is the default value” without being really explicit, but the documentation explains it, and changing now this behavior would probably annoy a lot of people that didn’t set any default value for their StatusField.

@nemesisdesign we would need a bit more context to help you, like your models, your migrations, …

[ivansche]

+1 I have a bunch of migrations which enumerate the possible statuses, but adding a new status does not seem to affect existing migrations