Re: django.contrib.admin and null=True

[schinckel]

On Dec 9, 1:57 pm, schinckel  wrote:
> On Dec 8, 2:02 pm, nasp  wrote:
>
> > You might consider 
> > readinghttp://docs.djangoproject.com/en/dev/ref/models/fields/#null.
>
> Thanks: that was the link I needed.
>
> However, I do take exception with the comment:
>
>     If a string-based field has null=True, that means it has two
> possible values for “no data”: NULL, and the empty string.
>
> An empty string means something different in the context of a
> relational database than a NULL value (as -RAX- and Andrew hint at
> below).  It goes a bit deeper than just unique constraints (although I
> have hit this several times), but also impacts upon relational
> algebra. (NULL and TRUE => NULL, for instance). Even just as a string,
> an empty string is different to NULL. An empty string means "I know
> what the value is, and it is a string of no length", compared to one
> use of a NULL, as "I don't know what the value is (yet)."
>
> In addition, NULL behaves vastly differently to an empty string when
> using COALESCE() or BOOL().
>
>     SELECT COALESCE(NULL, '', 'FOO'); => ''
>     SELECT BOOL(''); => ERROR
>
> Now, if you stay in django-land, this is probably not going to bite
> you too much (unless you want an optional IPAddress field in a
> Postgres db), but if you sometimes have to hand-tune queries (or
> *gasp* create stored procedures in your database), then you lose the
> ability to use COALESCE, for instance.

Having said all of that, I've just implemented a solution (using
pre_save), but there is an issue: it is not possible to know from the
admin interface returned value if the user meant to have a None value,
or an empty string.

Matt.

-- 
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.

Re: django.contrib.admin and null=True

[schinckel]

On Dec 8, 9:24 pm, -RAX-  wrote:
> By default Admin saves an empty string in those TextFields and
> CharFields defined as null = True.
>
> Whatever the semantic reasons are, this default behavior creates
> problems in those fields which are both unique = True and null = True
> because by saving an empty string they do not respect that null !=
> null.

Exactly!

> A work around of would be to override the form used by the admin
> interface replacing the empty strings with None.

Yeah, that's what I was doing. I do like Andrew's solution more
though: a global pre_save hook.

Matt.

-- 
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.

Re: django.contrib.admin and null=True

[schinckel]

On Dec 8, 2:02 pm, nasp  wrote:
> You might consider 
> readinghttp://docs.djangoproject.com/en/dev/ref/models/fields/#null.

Thanks: that was the link I needed.

However, I do take exception with the comment:

If a string-based field has null=True, that means it has two
possible values for “no data”: NULL, and the empty string.

An empty string means something different in the context of a
relational database than a NULL value (as -RAX- and Andrew hint at
below).  It goes a bit deeper than just unique constraints (although I
have hit this several times), but also impacts upon relational
algebra. (NULL and TRUE => NULL, for instance). Even just as a string,
an empty string is different to NULL. An empty string means "I know
what the value is, and it is a string of no length", compared to one
use of a NULL, as "I don't know what the value is (yet)."

In addition, NULL behaves vastly differently to an empty string when
using COALESCE() or BOOL().

SELECT COALESCE(NULL, '', 'FOO'); => ''
SELECT BOOL(''); => ERROR

Now, if you stay in django-land, this is probably not going to bite
you too much (unless you want an optional IPAddress field in a
Postgres db), but if you sometimes have to hand-tune queries (or
*gasp* create stored procedures in your database), then you lose the
ability to use COALESCE, for instance.

-- 
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.

Re: django.contrib.admin and null=True

[schinckel]

On Dec 8, 9:28 pm, Andrew Godwin  wrote:
> 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.

Yes, but don't we have new world order now? (GRIN).


> 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.

This looks like a good solution. I was just cleaning up the data in
the clean() method on a form,
but this is nicer. And global.

-- 
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.

Re: django.contrib.admin and null=True

[-RAX-]

By default Admin saves an empty string in those TextFields and
CharFields defined as null = True.

Whatever the semantic reasons are, this default behavior creates
problems in those fields which are both unique = True and null = True
because by saving an empty string they do not respect that null !=
null.
For instance suppose you want to create a TextField containing an
alphanumeric code which if exists is unique. The default behavior of
the Admin forms will save "" in all the empty fields violating the
unicity.

A work around of would be to override the form used by the admin
interface replacing the empty strings with None.

On Dec 8, 12:26 am, 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.

-- 
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.

Re: django.contrib.admin and null=True

[Andrew Godwin]

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.

Re: django.contrib.admin and null=True

[Ian Kelly]

On Tue, Dec 7, 2010 at 4:26 PM, schinckel  wrote:
> 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?

The issue with null IPAddressFields in the admin when using PostgreSQL is known:

http://code.djangoproject.com/ticket/5622

In the more general case, the Django philosophy on NULL vs. the empty
string is as explained in the link that nasp posted.

-- 
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.

Re: django.contrib.admin and null=True

[nasp]

You might consider reading
http://docs.djangoproject.com/en/dev/ref/models/fields/#null.

-- 
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.

django.contrib.admin and null=True

[schinckel]

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.

-- 
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.