Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#22537 closed Bug (fixed)

Misleading documentation on choices for a model field

Reported by: Mike Fogel Owned by: nobody
Component: Documentation Version: 1.6
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description

The docs on the choices attribute for a model field currently read "The first element in each tuple is the actual value to be stored..."

This is all true and good for simple model fields, but for more complex ones where the python representation of the field value differs from that in the database, this is at best misleading. An example of this is the 'hand' example of field subclassing in the docs. For fields like this one, the first element of the model choices field is the python representation of the field value, not the actual value to be stored in the database.

I've implemented a pull request that implements a minor documentation change clarifying this, and adds a test to the field subclassing to ensure this behavior is the blessed behavior.

Change History (3)

comment:1 Changed 5 years ago by Tim Graham

Triage Stage: UnreviewedAccepted

comment:2 Changed 5 years ago by Tim Graham <timograham@…>

Resolution: fixed
Status: newclosed

In 7fd1b35ed794e7d0a2a18f6ac168adba25a7de23:

Fixed #22537 -- Add tests and improved docs for field subclass with choices.

comment:3 Changed 5 years ago by Tim Graham <timograham@…>

In bb5c7e4e8d783bf3a2880ab5cf1fa57fd35cd198:

[1.7.x] Fixed #22537 -- Add tests and improved docs for field subclass with choices.

Backport of 7fd1b35ed7 from master

Note: See TracTickets for help on using tickets.
Back to Top