Those are good points. I am inclined to think the Django developers think along the same lines (that is why they suggest to "Avoid using null on string-based fields such as CharField and TextField unless you have an excellent reason")
Thus I am also inclined to think that CharField, ImageField etc would be treating an empty string "" and a database NULL as same in their code. I am trying to locate that code to know for sure, but haven't been able to yet. Regards. On Nov 25, 9:43 pm, Tim Valenta <tonightslasts...@gmail.com> wrote: > 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.
