System check error for tuples or lists in model field choices.

[Pedro Marcondes]

Since version 2.1 django stopped to accept tuples as value in choices.

I'll give you an example using the User model so you can reproduce. The error occurs when I do manage.py runserver.

I tried to find in the release notes from django 2.1.* versions but couldn't find something adressing this change. This model works with django version 2.0.10 and below.

from __future__ import unicode_literals
from django.db import models
from django.contrib.postgres.fields import IntegerRangeField


class Article(models.Model):

    LTE_50 = (1, 50)
    LTE_100 = (51, 100)

    SIZE_CHOICES = (
        (LTE_50, "1-50"),
        (LTE_100, "51-100"),
    )
  
    article_size = IntegerRangeField(choices=SIZE_CHOICES)
   """
   django.core.management.base.SystemCheckError: SystemCheckError: System check identified some issues:

   ERRORS:
   article.Article.article_size: (fields.E005) 'choices' must be an iterable containing (actual value, human readable name) tuples.
   """

    published = models.BooleanField("Is published", default=False)

    class Meta:
        verbose_name = "Article"
        verbose_name_plural = "Articles"

    def __str__(self):
        return "test"

[Tim Graham]

I think you could solve your issue and improve your code by using NumericRange in your choices instead of tuples. Now there may be other custom fields that want to use tuples for choice values, but perhaps we should address that if/when someone presents a use case.

[Pedro Marcondes]

Replying to Tim Graham:

I think you could solve your issue and improve your code by using NumericRange in your choices instead of tuples. Now there may be other custom fields that want to use tuples for choice values, but perhaps we should address that if/when someone presents a use case.

We tried to use 'NumericRange' but we got an error in serialization when trying to migrate. With further investigation we found that choices wasn't working(1.11.15~) with tuples even though it seemed to accept it as an option. Maybe django should support NumericRange serialization by default? Otherwise it's not possible to use the choices parameter out of the box.

[Carlton Gibson]

Bisected to f9844f484186fa13399bf8b96f58616687fe158a: "Fixed #28748 -- Made model field choices check more strict for named groups."

[Carlton Gibson]

OK, so the underlying issue here is that a tuple is not accepted as valid in ​the `is_value()` helper used during the checks.

I’m not at all sure that’s a universally valid restriction on choices. (???)

As such I’m inclined to Accept this as a Release Blocker on v2.1. (“Behaviour change from previous version”)

Happy for input to the contrary. (!!!)

[Tim Graham]

While it might require a lot of code duplication, a custom field that uses tuples as valid values could override Field._check_choices(). I'm not immediately convinced the issue is severe enough to require a patch for Django 2.1 but we could simply remove the new validation as it's not critical.

For this ticket's use case, NumericRange serialization is added in Django 2.2 (#29738).

If we decide to take no action for Django 2.1, we could leave this ticket open for someone to improve the validation. Actually, #20749 is already open for that.

[Carlton Gibson]

OK, lets downgrade this to Normal: the change in behaviour of the system check isn't quite a change in behaviour of the code itself. (The ​system check can always be silenced.)

• Implementing RangeField._check_choices() would be feasible.
• Maybe raising the is_value() helper to class level would allow avoiding too much duplication.
  • We may need to separate the is_value() logic from the is_human_readable_label() test — currently the is_value() helper is used for both tasks.
• Maybe a fix to #20749 addresses this too, but they don't seem quite the same. (I could see a fix for this without the more general problem being solved.)

[Carlton Gibson]

Test cased used for bisecting change. (Saved in postgres_tests

[CHANDAN PRAKASH]

I am new to this open source.
Help me in this issue.

[Carlton Gibson]

Hi Chandan.

First step is to read the contributing guide: ​https://docs.djangoproject.com/en/dev/internals/contributing/

Then your best bet, I think, is to take the test case I used and add it to the existing postgres test cases (you’ll need to have a look around as to where is best).

You’ll need to run against PostgreSQL to test. See ​https://docs.djangoproject.com/en/2.0/topics/testing/overview/#the-test-database

Then if you run the test suite you’ll see a failure. The test doesn’t currently pass. The task is to make it pass.

As per the discussion, implementing RangeField._check_choices() to override Field._check_choices() is the likely way forward.

Once you have something, even if not perfect, open a PR on GitHub and we can provide feedback.

Welcome aboard!

[Hasan Ramezani]

​PR

[GitHub <noreply@…>]

In a9bd01d3:

Refs #30095 -- Simplified Field._check_choices() a bit.

Using an internal is_value() hook to check whether Field.choices
is iterable is misleading.

[Mariusz Felisiak]

ArrayField with lists in choices are also affected.

[Hasan Ramezani]

Fix for ArrayField with lists in choices added.

[Mariusz Felisiak <felisiak.mariusz@…>]

In dc60597:

Refs #30095 -- Added Field._choices_is_value().

This allows fields classes to override the validation of choices'
values.

[Mariusz Felisiak <felisiak.mariusz@…>]

In 47379d02:

Fixed #30095 -- Fixed system check for RangeField/ArrayField.choices with lists and tuples.