AlterField operation should be noop when adding/changing choices on SQLite.

[David Szotten]

while writing a test case for #33470 i found that for sqlite, even a seemingly db-transparent change like adding choices still generates sql (new table + insert + drop + rename) even though this shouldn't be needed. on e.g. postgres the same migration generates no sql

[Mariusz Felisiak]

It was missed in #25253 (see 9159d173c3822312c653db7ff5b9a94b14af1dca). Adding choices to the non_database_attrs should fix it:

django/db/backends/base/schema.py

@@ -1130 +1130 @@
         # - adding only a db_column and the column name is not changed
         non_database_attrs = [
             'blank',
+            'choices',
             'db_column',
             'editable',
             'error_messages',

Would you like to prepare a patch? (a regression test is required).

[David Szotten]

oh i didn't realise that this was done globally by attr name. (though how come pg does the right thing?)

could marking choices as a non_database_attrs adversely impact third party fields that eg use a pg enum type to model choices values?

[Douglas Mumme]

Hey there, I'm new to this and trying to get into contributing to Django, but I would like to pick this ticket up and prepare a patch for it if no one is working on it right now. Please let me know if there is a problem with this, thanks!

[Douglas Mumme]

Just made a pull request with the patch to fix this ​https://github.com/django/django/pull/15404

[Mariusz Felisiak]

Replying to David Szotten:

could marking choices as a non_database_attrs adversely impact third party fields that eg use a pg enum type to model choices values?

True, this would cause a regression for-party enum fields, e.g. ​django-mysql's EnumField a similar field may exist for PostgreSQL or Oracle. It seems we can safely overwrite _field_should_be_altered() only on SQLite.

[Adam Johnson]

Indeed it would break Django-MySQL’s EnumField - ​docs / ​source.

If the "ignorable attrs" were extended on a per-field-class basis, that could work. It would be a bigger patch but it could allow many custom field classes to avoid unnecessary database changes.

[David Szotten]

do you know off the top of your head what mechanism makes it a no-op on pg already?

[Mariusz Felisiak]

Replying to David Szotten:

do you know off the top of your head what mechanism makes it a no-op on pg already?

There is nothing specific to PostgreSQL here, it's also a noop on MySQL and Oracle. It's caused by remaking tables on SQLite that is necessary in most of cases (see related ticket #32502). Overwriting _field_should_be_altered() in the SQLite backend should do the trick.

[Sarah Boyce]

I have added a PR which hopefully addresses the above comments: ​https://github.com/django/django/pull/15561

[Mariusz Felisiak <felisiak.mariusz@…>]

In 65effbdb:

Fixed #33471 -- Made AlterField operation a noop when changing "choices".

This also allows customizing attributes of fields that don't affect
a column definition.