Hi Margie,
On Fri, 2009-08-07 at 23:17 -0700, Margie wrote:
>
> 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)
Right, that won't do what you want. ChoiceField normalizes to a unicode
object.
>
> 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?
Correct.
> 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.
Also correct. The documentation says "Defaults to an identity function"
and all the data coming from a form submission are strings (Python
unicode objects), so if you don't supply the coerce parameter, it does
nothing.
It's probably a slight API wart that TypedChoiceField doesn't just raise
an exception if you don't supply coerce(). The default is slightly
dangerous, as it almost always means you're misusing the field. Not a
fatal flaw in the design, however.
>
> 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?
Yes. The django.db.models.fields.Field.formfield() method detects if you
have specified "choices" in the field and uses the Field subclass's
to_python() function as the coerce method.
> 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?
Actually, my SQLite observation was entirely bogus. I suspect what
you're seeing is the difference between these two lines:
t1 = Task.objects.create(status=u'3')
t2 = Task.objects.get(id=t1.id)
In this case, t1.status will be a unicode string, but t2.status will
always be an integer, no matter what DB backend is involved. So you are
seemingly stumbling over a case like the t1 situation -- where you're
using the object after it has been populated and saved, but still using
the raw data.
I've long argued that allowing the wrong types to be assigned to
attributes in Django models is a flaw (Python got rid of automatic type
coercion for operator arguments years ago for the same reason), but it's
been there forever in Django-years, so isn't going to go away now.
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
-~----------~----~----~----~------~----~------~--~---
