Changes between Initial Version and Version 1 of Ticket #23405, comment 14

Sep 8, 2016, 11:16:43 AM (8 years ago)
Tim Graham


  • Ticket #23405, comment 14

    initial v1  
    55<MarkusH> truecoldmind: what has blank to do with database default anyway?
    66<MarkusH> but I agree, you need to check for null
    7 * ojii has quit (Quit: Leaving)
    87<truecoldmind> I'm thinking due to 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
    98<MarkusH> blank is only used for form validation, iirc
    109<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
    1110<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?
    12 * tonebot has quit (Remote host closed the connection)
    13 * tonebot ( has joined #django-dev
    1411<truecoldmind> MarkusH, it will be good (reasons are explained in Due to,  `blank` is not necessarily associated with forms
    1512<truecoldmind> So I think that check in deconstuct "if self.blank and not self.null and self.default is NOT_PROVIDED" will be right
    1815<MarkusH> but yes, that should work
    1916<truecoldmind> MarkusH, okay, thanks for conversation. I will do more research about how changes in deconstruct will affect migrations and update PR later
    20 <MarkusH> Thank you for tackling the issue
Back to Top