[Django] #27239: Unexpected behavior on get_FIELDNAME_display when as int as value

4 views
Skip to first unread message

Django

unread,
Sep 18, 2016, 8:47:07 PM9/18/16
to django-...@googlegroups.com
#27239: Unexpected behavior on get_FIELDNAME_display when as int as value
----------------------------------------------+---------------------------
Reporter: levivm | Owner: nobody
Type: Bug | Status: new
Component: Database layer (models, ORM) | Version: 1.10
Severity: Normal | Keywords: choice, field
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------------------+---------------------------
Let's say we have have a choice field called gender and it has intengers
as values.


{{{
GENDER_CHOICES = (
(1, _('Male')),
(2, _('Female'))
)

gender = models.CharField(choices=GENDER_CHOICES, null=True)
}}}

If we create an instance with a gender as 1 or '1' and then try to
display gender field value using get_FIELDNAME_display method, we will get
unwanted value. We will get '1' and not 'Male' as it supposed to be.


{{{
Model.instance.create(gender=1)
instance.get_gender_display()
>>>'1'
}}}

The correct response should be

{{{
Model.instance.create(gender=1)
instance.get_gender_display()
>>>'Male'
}}}

--
Ticket URL: <https://code.djangoproject.com/ticket/27239>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Sep 19, 2016, 4:09:13 AM9/19/16
to django-...@googlegroups.com
#27239: Unexpected behavior on get_FIELDNAME_display when as int as value
-------------------------------------+-------------------------------------

Reporter: levivm | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 1.10
(models, ORM) |
Severity: Normal | Resolution:

Keywords: choice, field | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by claudep):

* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0


Comment:

Why would you use integer values for a CharField in the first place?

--
Ticket URL: <https://code.djangoproject.com/ticket/27239#comment:1>

Django

unread,
Sep 19, 2016, 4:14:58 AM9/19/16
to django-...@googlegroups.com
#27239: Unexpected behavior on get_FIELDNAME_display when as int as value
-------------------------------------+-------------------------------------

Reporter: levivm | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 1.10
(models, ORM) |
Severity: Normal | Resolution:
Keywords: choice, field | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by levivm):

Replying to [comment:1 claudep]:


> Why would you use integer values for a CharField in the first place?

Because it's possible. If Django allows you to assign it, so, it should
take care of that case.

--
Ticket URL: <https://code.djangoproject.com/ticket/27239#comment:2>

Django

unread,
Sep 19, 2016, 5:10:39 AM9/19/16
to django-...@googlegroups.com
#27239: Unexpected behavior on get_FIELDNAME_display when as int as value
-------------------------------------+-------------------------------------
Reporter: levivm | Owner: nobody
Type: Bug | Status: closed

Component: Database layer | Version: 1.10
(models, ORM) |
Severity: Normal | Resolution: duplicate

Keywords: choice, field | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by timgraham):

* status: new => closed
* resolution: => duplicate


Comment:

Duplicate of #20749 which suggests to add a system check to prohibit using
incorrect types in `choices`.

--
Ticket URL: <https://code.djangoproject.com/ticket/27239#comment:3>

Reply all
Reply to author
Forward
0 new messages