Malcolm Tredinnick wrote: >> Well, if the field is blank and if I said that I'd like to store >> NULL values in the model definition, I guess I want to store NULL in >> the database, not empty strings. If that's not the case, I'm >> probably good for the pshrink. :) > > No; in general (in databases), if you say the field can accept NULLs > then that means you want to be able to store undefined (NULL) values > in there as well as all other values (including empty strings). It > does not say you want empty to strings to be automatically converted > to NULLs. Django follows a similar pattern. > > It just happens that in your particular use case, you are > willing/wanting to equate empty strings with NULLs via the web input > interface. We cannot make that assumption in general, so the > framework makes a consistent, documented choice.
Ok, that makes sense: the framework mimics the database behavior. But speaking about consistency, I feel a bit odd that integer or boolean values are treated differently than string values. It seems that CharField is a sort of exception here. I perfectly understand the point, but don't you think it would be useful to give the user a mean of treating all kinds of input fields the same way? Do you realy think that a 'empty_asnull=True' option for CharFields would be useless? Whatever, thanks a lot for taking time answering my questions. Best regards, -- Kilian CAVALOTTI Administrateur réseaux et systèmes Université P&M Curie - LIP6 (C870) 8, rue du Capitaine Scott Tel. : 01 44 27 88 54 75015 Paris - FRANCE Fax. : 01 44 27 70 00 --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
