In most cases, any string field should be allowed to be blank, and can easily survive WITHOUT "null=True". As stated before me, this is preferable. For instance, you asked about FileField, among others. This is perfectly fine to only use "blank=True".
You'll primarily only be using "null=True" on fields that cannot actually be blank in the database. A Date/DateTime field, for instance. an empty string isn't a valid value in MySQL, therefore you must also use "null=True", to achieve the blank effect. The same goes for a BooleanField in Django. Again, a blank string isn't a valid boolean value, so null=True is required. In short, always try to make "blank=True" work out, and only pair it up with "null=True" when you're dealing with database fields that actually cannot legally have a blank string as a value. Tim On Nov 25, 8:58 am, Bill Freeman <ke1g...@gmail.com> wrote: > The major problem that I see with NULL in strings is that there may be > databases > out there that don't distinguish between NULL and "", that is that store them > the same way. > > "" is just as good in most cases. It behaves like False in python and > template tag > tests. And it has the advantage that if you go ahead and apply a > string operation > to it without checking first, it won't raise an exception because the > operation isn't > applicable to the None object. You can't test for it by using ISNULL > in SQL, but > unless NULL has a different meaning for you than "empty", who cares? > > There are certainly cases where you might, for example, want to > distinguish between > "never been set" or "is unset", and "displays as no characters", and you could > encode the former states as NULL. But you could also use a separate boolean. > Think about which code is going to be easier to maintain, especially > if by someone > else when they don't have you to talk to. If this table will have > billions of rows, then > it might be worth thinking about the memory consumed for that boolean, > But then > in an year and a half, hard drives will be twice as big. > > Still, python (and lisp and C) programmers are used to thinking about > the possibility > of None (or nil or (void *)0), so experienced programmers may have an easy > time > with maintenance or a NULL flag design. > > So, it's not a hard and fast rule. I still think that inconsistent > backend support is the > major factor. > > Bill > > > > On Tue, Nov 24, 2009 at 1:08 AM, chefsmart <moran.cors...@gmail.com> wrote: > > The Django docs suggest "Avoid using null on string-based fields such > > as CharField and TextField unless you have an excellent reason." > > > ImageField, EmailField, FileField, FilePathField, IPAddressField, > > SlugField, URLField, XMLField are also a string-based fields at the db > > level, so am I right in assuming that null=True is best avoided in > > these case also, "unless you have an excellent reason."? > > > I am hoping Django has code to deal with the empty string value in > > these fields. For example, I am hoping that Django understands that an > > empty string in an ImageField means there is no corresponding image. > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Django users" group. > > To post to this group, send email to django-us...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-users+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
