On Mon, 2009-01-05 at 23:39 -0700, Jeff Anderson wrote: > Malcolm Tredinnick wrote: > > The way to think about this problem is whether there's a situation where > > blank=True, null=False makes sense or is even possible for non-text > > fields and Mike quite possibly has a valid point there: you cannot store > > a blank value in a non-NULL integer field, for example. > > > I was trying to think of a way that a non-NULL "blank" integer would be > useful. I can't even think of how it would exist– it just doesn't make > sense. This thread may do well on the dev list. I believe that there is > a valid point here, and that at least Integer fields (and quite possibly > other non-text fields) should behave the way that Mike is describing.
I don't think we'd want to get too subtle here. Either it makes sense for all non-text fields, or it doesn't. We already have null being special for text-based fields (in the sense that it has no effect), so this wouldn't be introducing extra cases. But I'd be reluctant to go too fine-grained and end up with having to check a table in the docs to work out when blank => null and when it doesn't. That just makes things more confusing. After all, if we do nothing, it's hardly a tragedy. Fingers can handle typing null=True every now and again. But if there's a consistent solution, it'd make sense to use it. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
