On 6/3/07, Ian Harding <harding.ian@gmail.com> 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.
