On 07/12/10 23:26, schinckel wrote:
I haven't been able to find any documentation about this, but would be
happy to be pointed in the right direction.
When you use null=True in a field, and then use that model in the
admin, it will not save NULL to the database, but will instead save an
empty string (or attempt to).
I think this is broken behaviour: NULL values are semantically
different to empty strings, and in certain cases (I think it was
IPAddressField, but I will have another look later), it would fail to
write to the database.
Is there a reason that the admin interface saves what should be a NULL
value as an empty string? Do I report this as a bug?
Matt.
Further to the other two replies, this is a known issue, and affects
things like unique constraints too. The relevant bug -
http://code.djangoproject.com/ticket/9590 - was closed as WONTFIX a
while ago.
General opinion last time I asked about this (it bites me occasionally)
is that there's a divide between people who use NULL, and between people
who think there should be one empty value, but even if fixed it'd
probably break backwards compatibility in so many subtle ways, it's
unlikely to occur.
My suggested workaround is to add a pre_save hook that manually fixes
the fields up. Someone I know has one that runs against all saves on all
models, and auto-corrects any "" values in nullable fields to None
before saving them.
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
