Re: Charfields and Admin and None, oh my.

[Andrew Godwin]

On 11/11/10 01:40, Karen Tracey wrote:
>
> There is a way, it just requires some admin customization. See:
>
> http://stackoverflow.com/questions/454436/unique-fields-that-allow-nulls-in-django/1400046#1400046

Right, and you can also register a pre_save hook to fix this, but it's
just ugly.

>
> I don't think we can do anything now that would suddenly, when people
> installed a new level of Django, start storing nulls in cases where
> previously empty strings had been stored. Wouldn't we then likely be
> creating a situation where a table column winds up with some "empty"
> values equal to empty strings an others nulls? Having just one "empty"
> value is the reason empty strings are forced for null values,
> according to the doc. Personally I may wish null had been chosen as
> the empty value but I'm not sure we can safely make that change at
> this point. (I am tired, though, so maybe I am missing something in
> how this would not be a backwards-incompatible change?)

Yes, my main problem with this is backwards-compatability - as you say,
whenever people started saving forms again, things would suddenly become
None, which is never a Good Thing.

We could do it only when the field is unique=True null=True (since if
you have that chances are you _really didn't_ want an empty string), but
that also presents the additional weirdness of it changing only when
very specific field options are turned on.

The other options are to improve the error message a bit (but doing so
while keeping it end-user friendly is tricky) or to add an option to
ModelAdmin (because what that class needs is more options...)

But yes, the main issue here is the underlying issue that Django has
been using "" for empty strings since the start, which can be a divisive
issue amongst the developers I know. Something to chalk up for the
fabled Django 2, perhaps.

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: Charfields and Admin and None, oh my.

[Karen Tracey]

On Wed, Nov 10, 2010 at 6:32 PM, Andrew Godwin  wrote:

> So, I've been trying to trace a bug that's been affecting me as well as
> someone else I know, to do with ModelForms / the admin and CharFields
> with null=True, blank=True, and unique=True
>
> The old ticket for this was closed as WONTFIX:
> http://code.djangoproject.com/ticket/9590
>
> However, I'd personally rather see the admin work with this (more common
> than you think) combination of options; otherwise, there's no way to
> make more than one model with one of these fields via the admin, and
> it's basically useless.
>
>
There is a way, it just requires some admin customization. See:

http://stackoverflow.com/questions/454436/unique-fields-that-allow-nulls-in-django/1400046#1400046



> I'd propose we either ship a new CharField subclass (NullCharField,
> perhaps), or add an option to the existing one, which when it gets
> something in EMPTY_VALUES returns None, not u"". Then, modify ModelForm
> (and thus the admin) to use this new subclass if the field has null=True
> set.
>
> It's a pretty simple fix, and I don't think it's an excessively ugly
> thing to add one more option/subclass, especially when the resulting
> error is quite user-unfriendly ("This value must be unique" error beside
> a non-required, blank textbox).
>
>
I don't think we can do anything now that would suddenly, when people
installed a new level of Django, start storing nulls in cases where
previously empty strings had been stored. Wouldn't we then likely be
creating a situation where a table column winds up with some "empty" values
equal to empty strings an others nulls? Having just one "empty" value is the
reason empty strings are forced for null values, according to the doc.
Personally I may wish null had been chosen as the empty value but I'm not
sure we can safely make that change at this point. (I am tired, though, so
maybe I am missing something in how this would not be a
backwards-incompatible change?)

Karen

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

Charfields and Admin and None, oh my.

[Andrew Godwin]

So, I've been trying to trace a bug that's been affecting me as well as
someone else I know, to do with ModelForms / the admin and CharFields
with null=True, blank=True, and unique=True

The old ticket for this was closed as WONTFIX:
http://code.djangoproject.com/ticket/9590

However, I'd personally rather see the admin work with this (more common
than you think) combination of options; otherwise, there's no way to
make more than one model with one of these fields via the admin, and
it's basically useless.

I'd propose we either ship a new CharField subclass (NullCharField,
perhaps), or add an option to the existing one, which when it gets
something in EMPTY_VALUES returns None, not u"". Then, modify ModelForm
(and thus the admin) to use this new subclass if the field has null=True
set.

It's a pretty simple fix, and I don't think it's an excessively ugly
thing to add one more option/subclass, especially when the resulting
error is quite user-unfriendly ("This value must be unique" error beside
a non-required, blank textbox).

Thoughts?

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.