#23405: Blank-able CharFields require default=''
----------------------------+------------------------------------
Reporter: yuvadm | Owner: coldmind
Type: Bug | Status: assigned
Component: Migrations | Version: 1.7
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
----------------------------+------------------------------------
Comment (by coldmind):
{{{
<truecoldmind> MarkusH, consider the field
models.CharField(max_length=100, null=True, blank=True). In that case
default after deconstruct will be empty string, this is not correct.
<truecoldmind> The check can be "if self.blank and not self.null and
self.default is NOT_PROVIDED"
<MarkusH> truecoldmind: what has blank to do with database default anyway?
<MarkusH> but I agree, you need to check for null
* ojii has quit (Quit: Leaving)
<truecoldmind> I'm thinking due to
https://docs.djangoproject.com/en/dev/ref/models/fields/#null. Docs
recommends to not use `null=True` for char and text fields. It may not be
obvious that `blank=True` without `null` will give empty string, but, we
should definitely not set empty string as default if neither `blank` nor
the `null` was specified
<MarkusH> blank is only used for form validation, iirc
<truecoldmind> Yup. But, if no `blank` and `null` specified, user must
specify default by himself. We are now returned to South behavior (it sets
empty string if only `blank` was specified), but I don't know how to make
thing to be obvious
<MarkusH> truecoldmind: which turns us back to one of my previous
questions: Django's migrations are not equal to South's. Do we want to
have the same behavior here?
* tonebot has quit (Remote host closed the connection)
* tonebot (~node...@ec2-54-161-155-85.compute-1.amazonaws.com) has joined
#django-dev
<truecoldmind> MarkusH, it will be good (reasons are explained in
https://code.djangoproject.com/ticket/23405#comment:5). Due to
https://docs.djangoproject.com/en/dev/ref/models/fields/#blank, `blank`
is not necessarily associated with forms
<truecoldmind> So I think that check in deconstuct "if self.blank and not
self.null and self.default is NOT_PROVIDED" will be right
<MarkusH> truecoldmind: gnaah, sorry. Missed half the comment when reading
if before.
<MarkusH> not self.has_default() instead, right?
<MarkusH> but yes, that should work
<truecoldmind> MarkusH, okay, thanks for conversation. I will do more
research about how changes in deconstruct will affect migrations and
update PR later
<MarkusH> Thank you for tackling the issue
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23405#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/064.f4968526e108cbd9d2d657d2e14c5896%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
