Ordering of Field.choices is significant for makemigrations

[Marnanel Thurman]

makemigrations regards the ordering of Field.choices as significant. The docs require Field.choices to be an iterable, but not to be well-ordered. If Field.choices is not well-ordered, then almost every run of makemigrations will treat the model as changed, even without changes to the code.

The ordering of Field.choices is not significant anywhere else, except as a cosmetic detail in the admin.

This bug even occurs in

ACTIVITY_TYPES = set(['Create', 'Update', 'Delete'])

[....]
    f_type = models.CharField(
            max_length=255,
            choices=[(x,x) for x in ACTIVITY_TYPES],
            )

I would have expected the value of Field.choices here to be well-ordered (and sorted) but makemigrations still flags this as changed every time.

I can put a test case together if you like.

[Carlton Gibson]

I can put a test case together if you like.

Yes, please. Or a sample project that we can just run to play with. (Pending that I'll assume it reproduces. 🙂)

I need to look deeper to see exactly what's going on here, but there's at least a documentation issue:

An iterable (e.g., a list or tuple) ...

If it's required to be ordered it should say sequence or similar.

I'd suspect it's just been assumed that a list or tuple would be used. Maybe we can relax that. If not we'll have to change the docs.

[Marnanel Thurman]

Test case. Running makemigrations will create new migrations indefinitely

[Caio Ariede]

​PR

[Mariusz Felisiak]

This should be clarified in documentation, maybe "A :term:`sequence`" instead of "An iterable ..." or a note about ordering.

[Caio Ariede]

new ​PR

[Mariusz Felisiak <felisiak.mariusz@…>]

In 5248abe9:

Fixed #30505 -- Doc'd how changes in the order of Field.choices affect migrations.

[Mariusz Felisiak <felisiak.mariusz@…>]

In d6d65c1:

[2.2.x] Fixed #30505 -- Doc'd how changes in the order of Field.choices affect migrations.

Backport of 5248abe9b0425c1fc989c60a55860cdb4d135bcf from master