Hmmm, ok, after digging around I realize that full_clean was not
setting cleaned_data for the status field to an integer value;
cleaned_data['status'] was just getting set to something like u'1'.
I am in fact using sqllite, and yes, my status fields are just
integers:
OPEN_STATUS = 1
CLOSED_STATUS = 2
STALLED_STATUS = 3
I think the problem has to do with the way I created the status field,
which is like this:
self.fields["status"] = forms.ChoiceField
(choices=Task.STATUS_CHOICES, widget=StatusWidget(task=instance),
required=False)
I tried moving to TypedChoiceField(), but that didn't help. I
debugged into it in the case where I used TypedChoiceField() and I can
see that when coerce is called it isn't doing anything, it is just
returning the unicode value.
I find that if I do this instead, that it does do the coerce
correctly:
self.fields["status"].widget = StatusWidget(task=instance)
In looking at the doc it looks like the purpose of TypedChoiceField()
is to allow me to create my own coerce function, is that right? And
of course I wasn't doing that so it was behaving the same as
ChoiceField, and it looks like the default there is to just return the
unicode.
When I don't declare the status field at all (ie, just let django do
it's default thing), my guess is that it is choosing a coerce function
based on the integer type of my choices, is that true? I have never
used anything but sqlite3 so far, so I guess that was masking the
error and I would have run into this in a more serious way when I
moved to a different db?
Ok, cool, learn something new every day. Thanks for you pointers, if
you can just yay or nay my hypotheses above, that'd be cool.
Margie
On Aug 7, 7:39 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Fri, 2009-08-07 at 11:40 -0700, Margie wrote:
> > I see inconsistencies in how get_*_display() works based on whether
> > the object is a recently saved object. Probably an example describes
> > this best:
>
> > My model contains this:
>
> > class Task(models.Model):
>
> > STATUS_CHOICES = (
> > (OPEN_STATUS, 'Open'),
> > (CLOSED_STATUS, 'Closed'),
> > (STALLED_STATUS, 'Stalled'),)
>
> > status = models.IntegerField(choices=STATUS_CHOICES, blank=True,
> > null=True)
>
> I'm assuming OPEN_STATUS and friends are integers here (and not '1' or
> other strings that contain integers).
>
> [...]
>
> > However, if I have recently saved a modelForm associated with my Task
> > model and now have a handle to the object that that save() returned,
> > the status is in unicode, and get_status_display() doesn't return a
> > useful string:
>
> > (Pdb) type(self)
> > <class 'taskmanager.models.Task'>
> > (Pdb) self.status
> > u'3'
> > (Pdb) self.get_status_display()
> > u'3'
>
> If I create a standard ModelForm subclass for your task model and then
> submit some data to it (just using {"status": "1"} as the POST data
> dictionary), I cannot replicate your problem.
>
> The devil is in the details here. What does your ModelForm look like?
>
> The results you are seeing are consistent with the form somehow saving a
> string value for the "status" field. Which means (a) you're using
> SQLite, since other databases will complain about the type mismatch, and
> (b) something is going funky in your particular ModelForm.
>
> The get_FOO_display() method requires an exact match the choice value
> and the value of the field, otherwise it just returns the field value.
> Since 3 != u'3' in Python, it is returning the correct result, given the
> value of the status field. The question is how did you manage to get a
> string into the status field.
>
> Regards,
> Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
