Opened 13 years ago

Closed 11 years ago

#2122 closed (fixed)

get_FIELDNAME_display() fails on instance returned by

Reported by: bbarry@… Owned by: nobody
Component: Core (Other) Version: master
Severity: normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no


Invoking get_FIELDNAME_display() on a model instance returned by does not produce the expected result. After working with malcolmt on #django we decided it might be a good idea to file a ticket.

Problem: the value returned by get_FIELDNAME_display() is the string representation of the field itself rather than the decoded field value. The database seems to be intact, so I'd guess the severity/priority to be normal. Possible work arounds include using the saved instance (after extracting it from the db) rather than the instance returned by

Here's a simple example. I've included an "Example" model rather than the actual model to simplify the description of the problem.

    (0, 'foo'),
    (1, 'bar'),
    (2, 'baz'),

class Example(models.Model):
    ifield = models.IntegerField(choices=IFIELD_CHOICES,
    another_field = models.CharField(maxlength=16, blank=False)

    def __str__(self):
        return '%s: %s' % (self.get_ifield_display(), self.another_field)

    class Admin: pass

Given this model, the following code redirects to '1' when an Example is successfully saved. I'd expect it to redirect to 'bar'.

    def example_add_form(request):
        """Add an example to the db."""
        manipulator = Example.AddManipulator()
        new_data = {}
        errors = {}

        if request.POST:
            new_data = request.POST.copy()  # Need mutable POST data.
            errors = manipulator.get_validation_errors(new_data)
            if not errors:
                # Note: isinstance(new_data['top_level'], str)
                # returns True here
                example =
                return HttpResponse(example.get_ifield_display())

        # Create the form and load it into the example Django HTML template.
        form = forms.FormWrapper(manipulator, new_data, errors)
        return render_to_response('example.dht', {'form': form},

I'm using Ubuntu v.6.06, Apache v.2.0.55, Mod_python v.3.1.4, Python v.2.4.3, Django Rev.3103 (SVN).

I hope this helps. Please contact me if you need further clarification.

Change History (7)

comment:1 Changed 13 years ago by Home

Type: defect

comment:2 Changed 12 years ago by Gary Wilson <gary.wilson@…>

Needs tests: set
Triage Stage: UnreviewedAccepted

I confirmed that this bug still exists, but I'm not sure that it's worth fixing for manipulators. I'm marking this as accepted to make sure newforms doesn't have the some problem. Could someone please try this with newforms and report back.

comment:3 Changed 12 years ago by Gary Wilson <gary.wilson@…>

#2136 marked a duplicate of this.

comment:4 Changed 12 years ago by Gary Wilson <gary.wilson@…>

Just to add, the object returned by the method still has the ifield as a string instead of an integer and this seems to be what is causing the problem.

comment:5 Changed 11 years ago by Matt McClanahan

Resolution: fixed
Status: newclosed

Manipulators are gone, and the bug doesn't exist in ModelForms.

comment:7 Changed 11 years ago by Karen Tracey

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.
Back to Top