RoR, Judge Judy, and little old ladies

[Robby]

Andrei Alexandrescu (See Website For Email) wrote:
> 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

1 & 2 depend on a couple of things in relation to RoR.

Since classes absorb the schema of the table they represent, if a data 
type of a column changes, it can handle it in the means of generic find, 
save, etc. However, if there is logic in the code that depends on that 
type, it's obviously going to fail.

Again with the addition of a column, it's absorbed by the class (meaning 
that there is a property generated at runtime for access to the class 
implementation.

If a table is added RoR doesn't care about it, but you can't use it in 
an association, due to the fact that the machinery needed for 
represented associations needs to be generated against that new table.

So how does it handle changes? Pretty blindly, as long as your changes 
don't change any logic you've predetermined into some code. including 
associations (like belongs_to (where you've changed the name of the 
foreign key)

Bonus Question:
Rails is pretty ignorant of the relationships defined in the database 
itself DHH (author of RoR) has his reasonings listed here
http://www.loudthinking.com/arc/000516.html

I have read about hacks to get procs to work under oracle, though I 
really haven't invested any time to the situation, as I've never used 
the db (firebird mainly)

(Not Defending his choices, nor am I an authoritative voice on RoR, 
besides the couple of patches back to it, I'm just a user - though 
limited as of late).

If these answers don't answer what you're looking for feel free to let 
me know

Cheers,
Robby