#29656: Range Fields do not support blank values via ModelForm
----------------------------------+--------------------------------------
Reporter: James Addison | Owner: nobody
Type: Bug | Status: closed
Component: contrib.postgres | Version: master
Severity: Normal | Resolution: duplicate
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------+--------------------------------------
Comment (by James Addison):
Tim,
You could perhaps argue that the deficiency is the form widget that
doesn't allow distinguishing between null and an empty range.
I think this is exactly what I'm saying. As I see it, anyone who has
`null=False` (or has omitted it) on a `RangeField` has to have a similar
saving/cleaning hack to mine in place OR they don't use unbounded range
fields. Either way, a fix is appropriate for this scenario, no?
Maybe that's what some people want, but maybe it's not.
I'm not sure what else people in the "`null=False` with a default set"
scenario could possibly want other than the default value to be used if
the form fields were left untouched.
Where it does break... The only scenario where I think allowing `['', '']`
as a possible item in `empty_values` could break is for those who have
`null=True`, as my simplistic fix would replace the current `None` value
for `range([None, None])`. (Just guessing, but I'd think that many of
these would have used `null=True` simply to make range fields 'work' for
them.)
If that is the case, I can think of two possibilities:
1. put fix in place with a deprecation policy:
a. add `['', '']` into `empty_values` for `RangeField`s (addresses the
problem)
b. as a temporary deprecation measure: if `null=True` is used, add a
warning and override the value to be `None` if unbounded
c. in future, remove the deprecation measure as per Django policies
d. maybe advise to create a data migration to move nulls to empty ranges
as necessary
2. put fix in place for `null=False`, but leave `null=True` as is (ie.
always use `None` only if `null=True`)
The latter doesn't feel right to me, but I'm just tossing ideas at the
wall to see if anything sticks. Of course, I may have missed backward
incompatibility considerations - I appreciate any insight!
Lastly... Tim and Carlton, thanks for putting up with my feedback here.
If, after everything mentioned here, you tell me that this won't be fixed
because it is the ''desired'' path forward for Django, then I'll keep my
hack in place and keep quiet. After all, I don't think I can add anything
else at this point.
--
Ticket URL: <https://code.djangoproject.com/ticket/29656#comment:14>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.75469afb5f10514e814b016be511b333%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
