I'm sure it's possible that I haven't read the django docs properly; but I think my problem is actually that the Django docs don't speak to my usecase.
I don't care how the database stores empty values. Really, nothing is of less interest to me, I find the details of database schemata extremely boring. It can do empty strings or it can do NULL's, just so long as it gets out of my way. Also, I don't really care what the admin interface does, all these assignments are happening because I'm using the ORM from various scripts. The docs seemed to imply to me that if I followed the recommended practice of blank=True, null=False on a char string, then django would take care of all these issues, and store all empty/null values as an empty string. Super, sounds fine, that lets me not worry about the difference. Only that's not true; if I give Django a None object to store in a CharField, it tries to store a NULL, fails, and complains about it. What I had expected is that it would silently coerce the None to an empty string before writing to the database. I do understand (I think) what it's doing now, but a) It seems counterintuitive to me. b) to me, at least, the docs were misleading in this case. c) It still leaves me in the position that I have to add fragile code around my field assignments to turn all Nones into empty strings iff the field is a Char or TextField (which is something django would be able to do much better than me) Toby On Feb 13, 10:14 am, Praveen <praveen.python.pl...@gmail.com> wrote: > Hi Toby, you have not read properly the django docs. > > Note that empty string values will always get stored as empty strings, > not as NULL. > > only use null=True for non-string fields such as integers, booleans > and dates. > > For both types of fields, you will also need to set blank=True if you > wish to permit empty values in forms, as the null parameter only > affects database storage. > > Avoid using null on string-based fields such as CharField and > TextField unless you have an excellent reason. > > null is purely database-related, whereas blank is validation-related. > If a field has blank=True, validation on Django’s admin site will > allow entry of an empty value. If a field has blank=False, the field > will be required. > > but in your case you want to leave the field with no string then go to > back-end and change the value NULL to 'NOT NULL' to that field. > > On Feb 12, 8:35 pm, tow <toby.o.h.wh...@googlemail.com> wrote: > > > I know this seems to be a constant source of confusion; but I seem to > > have managed to confuse myself: > > > class TextData(models.Model): > > text = models.TextField(blank=True) > > > So I have a model with one textfield, whose value can be empty, and I > > don't want to worry about distinguishing NULLs and empty strings. > > perfect. So far so good according to the documentation. > > > obj = TextData() > > obj.text = '' > > obj.save() > > > ... works fine > > > obj = TextData() > > obj.text = None > > obj.save() > > > gives me an IntegrityError. Why? I don't care that whether that's > > saved as a Null or an zero-length string, I just want Django to save > > back my data according to whatever convention it's using for this > > field - the docs tell me if I do blank=True, then it'll use an empty > > string and not bother distinguishing nulls; or at least so they imply > > to me. But apparently it is trying to distinguish nulls, because it's > > given me an IntegrityError. I was expecting Django to coerce the None > > to an empty string before saving. > > > The reason why I'm doing this is because I'm filling up a model object > > (which actually contains lots of fields), based upon a dictionary > > which might be incomplete. > > > I really want to do something like: > > > d = incomplete_dictionary() > > obj = MyModel() > > for k in fieldnames; > > setattr(k, d.get(k)) > > > but I can't; that'll set missing fields to None. What I'm having to do > > instead is special-case all of the string values in order to set them > > to the empty string instead, which is rather more fragile. > > > Toby --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
