On 6/3/07, Martijn van Oosterhout <kleptog@xxxxxxxxx> 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.
