Malcolm Tredinnick wrote: > 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. Agreed– I simply haven't spent any time thinking about this particular problem in respect to any field other than an IntegerField. I can't think of any non-text field that it may not make sense with.
I have a hunch that a DateField could cause some confusion. Say I'm going to write a model, and I put in a date field. Is it a number? Is it a string? If it's a string, I have to explicitly include null=True. The way that one thinks of a datefield may vary from person to person, depending on their database experience and expectations. Without consulting any documentation, I'd be willing to bet that dates are more like numbers in this respect. I just set blank=True and hope that the null=True is set. What is a blank date anyway? "0000-00-00" might count as a 'blank date', as the month and day are invalid. To be sure, I'd have to look it up in a table in the documentation. I probably don't write models often enough to learn this answer and store it in my long-term memory. I might end up putting both blank=True and null=True just to be safe, and I've just defeated the purpose of the magic that we're proposing to put in anyway. What happens/should happen if I set blank=True and null=False? The "right answer" will probably vary based on who you ask, and it's one of those things that you just have to make room for on the Django cheat sheet and pencil in. Subtle magic is bad. A counter-argument against changing this behavior is "why are you setting blank=True on a field that simply can't be blank in the first place?" On an IntegerField (and friends) it just doesn't make sense, so it's likely that what I really mean is null=True, so that's what I should put in. Setting blank=True on an IntegerField doesn't cause any problems as far as I can tell, so the current behavior isn't at all destructive. The option is basically ignored. Django generally tries to stay away from "magic" as a rule of thumb, so leaving the behavior alone makes sense, and keeps things sweet and simple. It does catch a couple people off guard occasionally, which prompted this thread. Jeff Anderson
signature.asc
Description: OpenPGP digital signature
