RoR, Judge Judy, and little old ladies

[Andrei Alexandrescu (See Website For Email)]

BLS wrote:
> Andrei Alexandrescu (See Website For Email) schrieb:
>> 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?
> 
> In general this kind of problems are solved by
> implementing the observer - observeable/subject pattern.

Sorry, I'm not sure I understand. My understanding of the mechanism is 
the following:

1. The app runs a SQL-to-target-language parser to build an idea about 
the database.

2. The database folk changes the database in any number of ways. This is 
not a process that automatically notifies the target language application.

3. The target language application must undergo some change to 
accommodate the change in the database.

I did DB/financial work in 1998. This scenario was a total bitch because 
we didn't have small and fast test cases for all logic code to run when 
the database changed. Basically it was the customer (financial analysts) 
who let us know when something bombed, and they actually got so used to 
it that they even weren't pissed anymore.


Andrei