On 6/3/07, Martijn van Oosterhout <kleptog@svana.org> wrote:
> > For example, part of the point of having validations declared on the
> > model is so that you can raise user-friendly errors (and pipe them
> > through gettext for localization) such as "Your password must be at
> > least 4 characters long and contain only letters and digits".
> > Databases don't support this, and so applications end up having to
> > duplicate data-validation logic in order to find out what kind of user
> > input is invalid.
>
> I think you're confusing validation and integrity constraints. The
> example you're giving could be implemented in either the DB or the app.
No, I was pointing out that Rails supports uniqueness and referential
integrity, but that it implemented validations as a general construct
in order to (among other things) provide user-friendly messages.
But what I said also applies to uniqueness and foreign key
constraints. Databases, including PostgreSQL, makes it hard for an
application to determine what part of the data failed when it did. You
get an error for some arbitrary column, but not all columns; and the
error does not (as far as I know) actually contain the column that
failed.
> Personnaly I'd do it in the app since it's something that doesn't
> affect the integrity of the data. If I go in and manually change
> someone's password to something not following that rule it's not going
> to affect anything.
I agree with you and I don't; as it stands now, it's too hard to
implement validation in the database alone, for the reasons I stated
earlier. But I would love for it to be possible, so that I can be sure
that not even plain SQL can screw up the data.
Alexander.