On 06.01-08:03, dchandek wrote: [ ... ] >> 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?
i believe we are in agreement here but perhaps i may not be explaining myself sufficiently. you shouldn't set 'blank=True', you would set 'null=True'. this would (by default only) set 'blank=True' such that the validation would allow it to be blank as well as 'null'. a user could of course override this to set 'blank=False' if they desired. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
