On Thursday 04 May 2006 18:41, James Bennett wrote: > Per the model documentation, 'blank=False' does only apply when > entering a value in the admin[1].
Well, "If a field has blank=True, validation on Django's admin site will allow entry of an empty value." was not explicit enough for me to understand that it was only the case in the admin interface. I assumed it would occur unconditionally, according to models properties, no matter what application objects are created in. Perhaps it would be worth to mention explicitly that this option has effect (for now) in the admin interface only. > But that's not a very satisfying > answer, so here's a fuller explanation of what's going on in your > examples: > > The key difference here is between 'blank=False', which applies only > to the admin app, and 'null=False', which applies to the database. By > default, a field's 'null' attribute is False, which means the DB > column generated from the model will not accept a value of NULL. You'd > think this would result in an error when you try to save any field > with a null value, but this is actually dependent on the *type* of > field, which is why there's an apparent inconsistency. > > A CharField translates to a Python string, which means that when you > don't enter a value it translates to an empty string. Which, because > it's not the value NULL, is accepted by the DB. An IntegerField, > however, translates to a Python int, which does not have an "empty" > variation as strings do, so I'd imagine that not filling it in results > in conversion to... NULL. Which the DB rejects. I had such an intuition, but your detailed explanation clarified it to me. Thanks. > So long as you're only using the admin app to create objects, this > will be fine, but if objects are going to be created from other views > you'll want to set up a custom manipulator which raises an exception > when the CharField is left blank or, if you're going to be creating > objects programmatically as in your examples with the Python > interpreter, you'll want to override the model's save() method to make > it raise an exception when the incoming value for the CharField is an > empty string Right, it makes sense. However, I would continue to think that enforcing objects 'limitations' in the admin interface only could lead to mistakes. And that creating custom validation procedures for other views is an unneeded overhead for the developer: it could be done in the framework, since models already have many different types of properties, each with its own kind of limitation. So I would found natural to validate properties values when you do save() rather than only implement them in a specific application. Don't misinterpret me here, it's not moronic criticism, I'm really amazed by django possibilities, and I'd only like to highlight the 'perfectionist' side of the motto. :) Best regards, -- Kilian CAVALOTTI Administrateur réseaux et systèmes UPMC / CNRS - LIP6 (C870) 8, rue du Capitaine Scott Tel. : 01 44 27 88 54 75015 Paris - France Fax. : 01 44 27 70 00 --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
