On 6/3/07, Ian Harding <harding.ian@xxxxxxxxx> wrote:
> An empty string is not null! Null means the value is missing, which is > clearly not the case here. I would say Rails is exactly in the right > here. When an HTML form is posted, empty input boxes are declared as > empty strings, which what the user entered. The problem is not with > Rails/ActiveRecord but with your form handling. If you want empty > boxes to become null, add some client-side JavaScript logic that sets > the "disabled" attribute on empty input elements before form is > submitted; this will prevent the client from sending the value. The user was presented an _opportunity_ to enter data and did not. The data is unknown. I don't know how you can say "...The user entered" an empty string. There is no empty string key on the keyboard.
Not at all. If the input box already contained a string, and the user erased the contents of the input box, then the user has, in effect, entered an empty string. Not a "null". This is a UI layer issue, not a database issue.
I have no idea why I got such hard pushback on this. This is the EXACT same behaviour other types use. If a number field is presented to the user and submitted with no value, NULL Is inserted. Not zero, which is the numeric equivalent of the empty string, but NULL. Same with date types. Why not say they entered '1/1/1970' by default if they entered nothing?
Ah, no. An empty string is not a valid number -- in fact, it is the absence of a number; the same goes for dates. An empty string, however, is a valid string, since a string is (in this context) defined as a sequence of 0 to n characters.) Your patch is awful because it would mean there was no way to enter an empty string in the database. A one-character string containing a single space is not an empty string. Alexander.