On Sun, 2007-06-24 at 08:35 -0700, Mads Sulau Joergensen wrote: > Hi. > > Having looked at #2855 and wondered the resolution of that ticket,
There's been no resolution on that ticket, from what I can see. Still open. > i > wanted to raise the discussion again. > > To me, and many others, it makes absolutly no sense, that a > BooleanField with no default value given, sould yield a SQL error > uppon saving it. Since that is what happens with every other field, it's logical behaviour, though. To be consistent, you would have to argue that every field without a default attribute should have some default value and we've already decided in the negative on that one. Saving a model that you haven't validated is bad practice in Django. The validation and saving processes have been separated by design. The reason for that has been explained in other posts on this list over the years. > The ticket states that a BooleanField should be given a default value > of False, and that null's should not be allowed, and I can only say > that i agreed with that. After all, that is what NullBooleanField is > there for - right? There seems to be some confusion in that ticket as to both what the ticket is about and what the purpose of NullBooleanField is. Remember that some field types in Django have a history behind them and that history is often "was needed for something back in 2004 before Django was open-sourced." Firstly, the consistency points: any field without null=True specified in the model needs to have a value set. That is true for all fields; shouldn't be an different for BooleanField. Secondly (and this is the historical legacy issue), NullBooleanField is an example of a leaky abstraction: it's a field that, when you present it to the user on a form, is intended to be a tri-state: true/false/unknown. BooleanField, in a form context, is only a binary field: true/false. So the difference between NullBooleanField and BooleanField is presentational. However, that isn't really a strong argument for saying you can't put null=True on BooleanField, because models data storage is, ideally, independent of presentation. It will mean exactly what it means for all other fields (consistency again): the value is not yet determined. Assertions that BooleanField can *only* be true or false is working backwards from form presentation and/or trying to justify NullBooleanFields existence. I don't find either of those arguments as particularly compelling. The fact that we have NullBooleanField for legacy reasons does not mean that BooleanField should behave specially and somehow different from other fields. Consistency is very important for developers: having an API that behaves as one expects is a time-savers and leads to less bugs. By and large, you can ignore NullBooleanField and your life will not be any worse off. Consistency in API seems to imply that "null=True" should always works and permits empty values to be stored. It also means fields without a default need a value to be set. I haven't looked at that ticket for a while, but I'm inclined to say it's not a bug. Will wait to here for input from some other core developers first, though, since Jacob and Adrian were there at the time and might have other motivations or knowledge (I'm pretty strong no data/presentation separation -- with good reason and because it's what all right-thinking people do :-) -- but that doesn't mean it's the way we always go). Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
