Oops. I accidently didn''t cc this response to the list. --cjs
---------- Forwarded message ----------
Date: Thu, 9 Dec 2004 16:51:04 +0900 (JST)
From: Curt Sampson <cjs-gHs2Wiolu3leoWH0uzbU5w@public.gmane.org>
X-X-Sender: cjs-M8Hx/GUlm+vLsucy9qjBJ6EtEFPD+DI00e7PPNI6Mm0@public.gmane.org
To: Bob Sidebotham
<bob.sidebotham-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [Rails] type system
On Wed, 8 Dec 2004, Bob Sidebotham wrote:
> I don''t know anything about database validation of data...
> What sort of errors do you get back?
It depends on the validation being done. Here are some typical scenarios:
o A row with the primary key you gave for the new record already
exists in the table. (E.g., article #17 already exists.)
o When inserting into a table that references another, the data for
the column you were referencing does not exist in that other table.
(E.g., you can''t enter a response to article #21, becuase there is
no article #21.)
o A row in a table referencing this table references the row you''re
trying to delete, you did not specify a cascading delete, and the
database designer specified that cascading deletes were not the
default case. (You can''t delete article #17 because it has
responses
attached to it.)
o A column datum did not pass a constraint on that column or for
that type, such as the datum being null, a string being too long, or
not being all lower-case, or whatever was specified by the schema
designer.
Really, all a constraint specification in a DBMS is, is a type
specification without a name. I could create a new type called "lower
case string" and then create a column of that type, or I could just put
that constraint on a string column. Either way, what this is effectively
doing is making the database guarantee that when you select something
out of that column, you are always going to get a specific type of data.
> Do you have to write error interpretation code, anyway, if you want to
> give a sensible error to the user. As opposed to, say, "bad
value",
> I''d rather be able to emit messages that are as specific and user
> friendly as possible.
Yes, you would have to do that, though you could always, at least in
PostgreSQL, implement a sophisticated constraint as a function that
raises an exception with a specific error message, which you could then
show to the user.
> > 3. Validation information from the database. The ideal thing here
> > is that if you know what your database constraints are,
you''d like
> > efficiently to have the database do the validation itself rather
> > than write that validation code a second time in Ruby.
>
> But you''d still like an interface that made this transparent--that
is,
> it shouldn''t matter whether the error was generated by the
database or
> by the ruby code, from above, it should just look like a type
> error....
Right.
> ...then you''re getting to the point where you could
> generate the database schema from the Ruby record definitions.
I''ve looked at doing this several times, both in Ruby and in other
languages, but it''s a fair amount of work if you''re writing
reasonably
sophisticated database code, and I''ve never managed to figure out what
advantage it gives me over just doing the DDL in SQL.
cjs
--
Curt Sampson <cjs-gHs2Wiolu3leoWH0uzbU5w@public.gmane.org> +81 90 7737
2974 http://www.NetBSD.org
Make up enjoying your city life...produced by BIC CAMERA