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.
{{{#!python
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"
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30095>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* component: Uncategorized => Database layer (models, ORM)
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:1>
Comment (by Pedro Marcondes):
Replying to [comment:1 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:2>
Comment (by Carlton Gibson):
Bisected to f9844f484186fa13399bf8b96f58616687fe158a: "Fixed #28748 --
Made model field choices check more strict for named groups."
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:3>
* severity: Normal => Release blocker
* stage: Unreviewed => Accepted
Comment:
OK, so the underlying issue here is that a tuple is not accepted as valid
in
[https://github.com/django/django/blob/87bf35abd3df1015d0c08a9251739d6c8454ab32/django/db/models/fields/__init__.py#L246-L247
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. (!!!)
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:4>
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:5>
* severity: Release blocker => Normal
Comment:
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 [https://docs.djangoproject.com/en/2.1/ref/settings/#silenced-system-
checks 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.)
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:6>
* Attachment "regression_30095.py" added.
Test cased used for bisecting change. (Saved in `postgres_tests`
* status: new => assigned
* owner: nobody => CHANDAN PRAKASH
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:7>
Comment (by CHANDAN PRAKASH):
I am new to this open source.
Help me in this issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:8>
Comment (by 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!
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:9>
* owner: CHANDAN PRAKASH => Hasan Ramezani
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/11930 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:10>
* needs_better_patch: 0 => 1
* version: 2.1 => master
* needs_tests: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:11>
Comment (by GitHub <noreply@…>):
In [changeset:"a9bd01d363376d2e88f96cbf81bc6b77b0ff2bce" a9bd01d3]:
{{{
#!CommitTicketReference repository=""
revision="a9bd01d363376d2e88f96cbf81bc6b77b0ff2bce"
Refs #30095 -- Simplified Field._check_choices() a bit.
Using an internal is_value() hook to check whether Field.choices
is iterable is misleading.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:12>
* needs_better_patch: 1 => 0
* needs_tests: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:13>
* needs_better_patch: 0 => 1
Comment:
`ArrayField` with lists in choices are also affected.
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:14>
* needs_better_patch: 1 => 0
Comment:
Fix for `ArrayField` with lists in choices added.
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:15>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"47379d027ba2786403969367ec9c721936a823f8" 47379d02]:
{{{
#!CommitTicketReference repository=""
revision="47379d027ba2786403969367ec9c721936a823f8"
Fixed #30095 -- Fixed system check for RangeField/ArrayField.choices with
lists and tuples.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:17>
Comment (by Mariusz Felisiak <felisiak.mariusz@…>):
In [changeset:"dc60597eb643814e54fbb0f7dadfe68c634e52fa" dc60597]:
{{{
#!CommitTicketReference repository=""
revision="dc60597eb643814e54fbb0f7dadfe68c634e52fa"
Refs #30095 -- Added Field._choices_is_value().
This allows fields classes to override the validation of choices'
values.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30095#comment:16>