> i would be against unifying the options as i can imagine a more complex > environment (i.e. a database trigger or complex type not known to > django) where there may be a distinction and i believe the current > distinction is a clear one. it may be worthwile to imply that setting > 'null=True' also sets 'blank=True' unless explictly overridden with > 'blank=False'. however, the converse implication is faulty (i.e. > 'blank=True' != 'null=True') because 'blank' relates to the admin > interface, whereas 'null' refers to the data model. it is correct to > imply the interface and formatting from the data model but not to > imply the data contraints from the interface. IMHO.
The only gotcha I've encountered here is that practically speaking null=True requires blank=True. I'm not sure I'd want that setting to be automatic, though. It seems silly, for example, to have to set blank=True in order for a non-value in a ForeignKey to validate, since a blank value makes no sense. But shouldn't this be addressed in the validation code? --David --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
