RoR, Judge Judy, and little old ladies

[Andrei Alexandrescu (See Website For Email)]

After yesterday's hubbub, Judge Judy called and punished me to read 
about RoR, in addition to the obligatory sentence of helping a little 
old lady cross the street five times a week.

So I went and read the nice tutorial at:

http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html

I have a couple of questions that I assume will be easy to answer by 
anyone who actually has used RoR.

On the second page of the tutorial, the authors describe how they write 
SQL code to create tables, and then how they invoke Ruby to parse that 
SQL code and generate (I assume) Ruby wrappers for it.

Now consider that the database changes: new tables, new fields, 
different types for existing fields, etc.

1. Is now the generated Ruby code is out of sync with the database?

2. In case it is out of sync, what is the way to bring it back in sync? 
Manual editing of the Ruby code? Editing the SQL and then regenerating 
the wrappers? Some automated way?

An additional question: most interesting work in databases is done 
through views (SELECT statements) and stored procedures. Can Ruby parse 
such stuff and generate appropriate wrappers? If so, what happens when 
the views and stored procedures change?

I'm asking these questions because I want to figure whether automating 
the task of keeping in sync with a database, plus the additional type 
safety and speed, are significant advantages in the Web/DB domain. In 
such a scenario, error messages like the one in Part 2 
(http://www.onlamp.com/pub/a/onlamp/2007/01/05/revisiting-ruby-on-rails-revisited-2.html?page=4) 
may be avoided; the code simply fails to compile. I know of domains 
where such advantages are very important, but I'm not sure how the 
Web/DB domain feels about it.


Andrei