Re: string-based fields and null
On Thu, Nov 26, 2009 at 2:25 PM, chefsmart <moran.cors...@gmail.com> wrote: > 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. > > I wouldn't have thought that would be true. Unless you specify 'null=True' on a CharField, django will do its best to stop you ending up with a NULL value in the database. Eg, in MySQL it will create the field with the modifier 'NOT NULL'. Empty string and NULL/None are different values, both in the database and django. By disallowing NULLs, you just get a more consistent definition of empty string. For example, one of my models has an ImageField defined as: logo = models.ImageField( upload_to="uploads/logos", blank=True ) The db field that this corresponds to looks like this in MySQL (hope you are using a proportional font): +--+--+--+-+-++ | Field| Type | Null | Key | Default | Extra | +--+--+--+-+-++ | logo | varchar(100) | NO | | NULL || If I look at a model that has a blank logo field, then it looks like so: >>> m.logo If you are interested in knowing how ImageFields behave, perhaps try creating a few models with ImageFields, with various options and test how they behave? Might be a bit more promising than speculating. Cheers Tom -- 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.
Re: string-based fields and null
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.
Re: string-based fields and null
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.
Re: string-based fields and null
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 at > http://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.
string-based fields and null
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 at http://groups.google.com/group/django-users?hl=en.
