Re: [Django] #4136: NULL fields and Unique keys
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner: nobody
<dcramer@…> | Status: new
Type: Bug | Version: 0.96
Component: contrib.admin | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 1
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by anonymous):
* ui_ux: => 0
* easy: => 0
Comment:
Any news about this? Is this still open?
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:11>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner: nobody
<dcramer@…> | Status: new
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 1
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
* version: 0.96 => 1.3-rc1
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:12>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner: nobody
<dcramer@…> | Status: new
Type: Bug | Version: 1.3-rc1
Component: contrib.admin | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 1
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by federico.capoano@…):
How am I supposed to do in a case like:
{{{
ipv4_address = models.IPAddressField(verbose_name=_('ipv4 address'),
blank=True, null=True, unique=True, default=None)
ipv6_address = models.GenericIPAddressField(protocol='IPv6',
verbose_name=_('ipv6 address'), blank=True, null=True, unique=True,
default=None)
}}}
No idea on how to solve this.
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:13>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner: nobody
<dcramer@…> | Status: new
Type: Bug | Version: 1.3-rc1
Component: contrib.admin | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 1
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by calvinspealman):
I think this is more appropriately placed in the Forms component, as it
can be a problem with any form, not just those in the admin. At the heart
of the issue is a mismatch between the option combinations available to
form and model fields, and to solve it, form fields would need to
understand the difference between submitting an empty value and no value,
which HTTP form encoding does not make straight-forward without adding
additional flags.
Given that, I am not sure this is something django *should* be dealing
with, if it weren't for its own use of forms in the admin, so any solution
should be 1) easy to use with any form, 2) but not required nor adding
complexity to their existing behavior and usage, and 3) not part of the
admin.
I like the idea of providing an OptionalWidget which can wrap other
widgets, render them a checkbox to control if they are actually included,
and easiyl used in forms without changing any existing usage or behavior.
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:14>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner: nobody
<dcramer@…> | Status: new
Type: Bug | Version: 1.3-rc1
Component: contrib.admin | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 1
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
* cc: ironfroggy@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:15>
Django
-------------------------------------+-------------------------------------
<dcramer@…> | Status: assigned
Component: contrib.admin | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 1
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
* status: new => assigned
* owner: nobody => zefciu
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:16>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner: zefciu
<dcramer@…> | Status: assigned
Type: Bug | Version: 1.3-rc1
Keywords: | Needs documentation: 1
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by zefciu):
* component: contrib.admin => Forms
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:17>
Django
-------------------------------------+-------------------------------------
<dcramer@…> | Status: new
Component: Forms | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 1
Needs tests: 1 | UI/UX: 0
Easy pickings: 1 |
-------------------------------------+-------------------------------------
Changes (by zefciu):
* status: assigned => new
* needs_better_patch: 0 => 1
* needs_tests: 0 => 1
* easy: 0 => 1
* owner: zefciu => nobody
* has_patch: 0 => 1
Comment:
I have created a `NullableWidget`, which accepts as its first argument
another Widget. It renders a checkbox and its subwidget alongside and can
correctly decompress and get value from datadict. Also wrote some tests.
What is still needed:
* Enabling `None` in fields.
* Writing tests for different subwidgets and fields.
* !JavaScript for disabling the subwidgets on uncheck (?)
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:18>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner: nobody
<dcramer@…> | Status: new
Type: Bug | Version: 1.3-rc1
Component: Forms | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 1
Has patch: 1 | Patch needs improvement: 1
Needs tests: 1 | UI/UX: 0
Easy pickings: 1 |
-------------------------------------+-------------------------------------
Comment (by frostnzcr4):
I update zefciu patch with redefined _has_changed method and now save not
throw exceptions anymore. But new problem is that CharField convert
''None'' value to empty string (''u""'') and save of another model
instance with CharField set to None throws unique error again. So the root
of the evil is in null and blank attributes again, not in unique itself?
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:19>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner: nobody
<dcramer@…> | Status: new
Type: Bug | Version: 1.3-rc1
Component: Forms | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 1
Has patch: 1 | Patch needs improvement: 1
Needs tests: 1 | UI/UX: 0
Easy pickings: 1 |
-------------------------------------+-------------------------------------
Comment (by aashu_dwivedi):
A somewhat related ticket is https://code.djangoproject.com/ticket/5622
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:20>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner: nobody
<dcramer@…> | Status: new
Type: Bug | Version: 1.3-rc1
Component: Forms | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 1
Has patch: 1 | Patch needs improvement: 1
Needs tests: 1 | UI/UX: 0
Easy pickings: 1 |
-------------------------------------+-------------------------------------
Comment (by akaariai):
Maybe a new form field init argument is needed: blank_as_none? Better name
welcome. I don't see any other way forward. Currently it is impossible for
the form layer to know if the given empty value should be treated as "" or
None.
Maybe we need a matching model field init argument, too. Setting
null=True, blank=True can not be translated to blank_as_none, as this
would be backwards incompatible.
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:21>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner: nobody
<dcramer@…> | Status: new
Type: Bug | Version: 1.3-rc1
Component: Forms | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 1
Has patch: 1 | Patch needs improvement: 1
Needs tests: 1 | UI/UX: 0
Easy pickings: 1 |
-------------------------------------+-------------------------------------
* cc: aashu_dwivedi (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:22>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner:
Type: Bug | Status: assigned
Component: Forms | Version: 1.3-rc1
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by aashu_dwivedi):
* owner: nobody => aashu_dwivedi
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:23>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner:
<dcramer@…> | aashu_dwivedi
Type: Bug | Status: assigned
Component: Forms | Version: 1.3-rc1
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: m.r.sopacua@… (added)
Comment:
Just to throw in my 2 cents here: if this is a general form problem the
answer is not a special widget with a 'NULL' description as users of a
site should not be expected to know the difference, which means one should
be able to describe in the field's init method what the description of the
radio buttons should be, like (..., provided_value="My cat's name",
absent_value="I have no cat").
Also the simplest option is to always insert as NULL if null and unique
are True as there are very few real world cases where an empty value is an
actual valid option. One could also make this case for non-unique but null
fields, however there's no actual distinction between a NULL value and an
empty string in this case.
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:24>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner:
<dcramer@…> | aashu_dwivedi
Type: Bug | Status: assigned
Component: Forms | Version: 1.3-rc1
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by anonymous):
I do think that the best way forward seems to be msopacua's solution.
Please share your opinion on the same so that it can be taken forward and
fixed as soon as possible.
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:25>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner:
<dcramer@…> | aashu_dwivedi
Type: Bug | Status: assigned
Component: Forms | Version: 1.3-rc1
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by aashu_dwivedi):
I do think that the best way forward seems to be msopacua's solution.
Please share your opinion on the same so that it can be taken forward and
fixed as soon as possible.
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:26>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner:
<dcramer@…> | aashu_dwivedi
Type: Bug | Status: assigned
Component: Forms | Version: 1.3-rc1
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by hongshuning):
I agree with msopacua's solution, and suggest to change component from
Forms to contrib.admin because programmers should write their own form
code to control it. The 'blank' parameter may only be used for admin app.
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:27>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner:
<dcramer@…> | aashu_dwivedi
Type: Bug | Status: assigned
Component: Forms | Version: 1.3-rc
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
-------------------------------------+-------------------------------------
Changes (by carljm):
* easy: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:28>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner:
<dcramer@…> | aashu_dwivedi
Type: Bug | Status: assigned
Component: Forms | Version: 1.3-rc
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Ankit Bagaria):
I want try to solve this issue can someone pleaseguide me as to where do I
start..
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:29>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner:
<dcramer@…> | aashu_dwivedi
Type: Bug | Status: assigned
Component: Forms | Version: 1.3-rc
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by carljm):
msopacua's suggestion is incomplete because it only considers the model-
field API. Form fields don't even have a "blank" argument (they have
"required"), so a different API would have to be proposed for them.
Ultimately this is a form-field issue (we only need the option at model-
field level to give a hint to modelform generation).
The `NullableWidget` is a bad general solution for the reason msopacua
notes: in most cases end users don't know and shouldn't have to care about
the difference between storing null and empty string; this is a concern
for the application developer.
At the form field level, I think perhaps the best approach is similar to
what akaariai suggested; a new `default_if_empty` option to
`forms.CharField`, defaulting to the empty string, that defines what is
returned from `to_python` if `value in self.empty_values`.
At the model-field level, my objection to msopacua's suggestion is that it
implicitly applies to all field types (since they all have the `blank`
option), but I think this issue is only relevant for `CharField`. If there
were no backwards-compatibility concerns, I think the right behavior would
be to simply automatically pass `None` to the form field's
`default_if_empty` if `null=True`. I'm somewhat tempted to just go ahead
and do this and note it in the backwards-compat notes, because I think in
most cases if `null=True` it is the desired behavior. If that's too much
of a back-compat break, I guess we would need a new option to `CharField`
to enable that behavior.
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:30>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner:
<dcramer@…> | aashu_dwivedi
Type: Bug | Status: assigned
Component: Forms | Version: 1.3-rc
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: riccardo.magliocchetti@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:31>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner:
<dcramer@…> | aashu_dwivedi
Type: Bug | Status: assigned
Component: Forms | Version: 1.3-rc
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by msopacua):
Replying to [comment:30 carljm]:
> msopacua's suggestion is incomplete because it only considers the model-
field API. Form fields don't even have a "blank" argument (they have
"required"), so a different API would have to be proposed for them.
Ultimately this is a form-field issue (we only need the option at model-
field level to give a hint to modelform generation).
I still think this is a model issue. For one, because the issue exists in
translating model data to storage. Secondly, because I can think of a
case, where the form would not present an empty string but the model might
- like a bad word filter. For me the logical place to put such a thing
would be in a model's clean(), but a case can be made to do this at the
form level.
> At the model-field level, my objection to msopacua's suggestion is that
it implicitly applies to all field types (since they all have the `blank`
option), but I think this issue is only relevant for `CharField`.
True. I don't mind this being a charfield only option, if it gets picked
up by custom fields that derive from it. You'd name it differently and
only apply it to `CharField`.lll
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:32>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner:
<dcramer@…> | aashu_dwivedi
Type: Bug | Status: assigned
Component: Forms | Version: 1.3-rc
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: cmawebsite@… (added)
Comment:
Seems to this actually applies to any fields that allow empty strings.
It's either the form or the model's responsibility to automatically
translate the blank strings into None in this case.
I usually work around the problem by putting this in my model's `save()`
method:
`self.myfield = self.myfield or None`
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:33>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner:
<dcramer@…> | aashu_dwivedi
Type: Bug | Status: assigned
Component: Forms | Version: 1.3-rc
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by anentropic):
@collinanderson
Can you elaborate? Simply adding that to the model `save()` method alone
seems to be insufficient because commonly we are using a `ModelForm` and
that calls the instance's `validate_unique` method, which raises
`ValidationError` before the `save` method is reached...
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:34>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner:
<dcramer@…> | aashu_dwivedi
Type: Bug | Status: assigned
Component: Forms | Version: 1.3-rc
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by collinanderson):
You probably have one entry that has an empty string instead of null.
Change that to null/none and that should fix the uniqueness problem. If
you use my code in your save method, you just need to call save on that
object.
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:35>
Django
-------------------------------------+-------------------------------------
Reporter: David Cramer | Owner:
<dcramer@…> |
Component: Forms | Version: 1.3-rc
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: aashu_dwivedi =>
* status: assigned => new
* needs_docs: 1 => 0
* needs_tests: 1 => 0
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/4136#comment:36>