RoR, Judge Judy, and little old ladies

[Bruno Medeiros]

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

Hum, in the context of the previous discussion of 1.005 features, I too 
have been trying to understand what makes Rails so special. After 
reading that article, it is my understanding that most of the goodness 
of Rails comes from the ability to generate Ruby code from the 
database's SQL schema, where that Ruby code handles all or most of the 
ORM logic. Is that correct? If so, is there anything special about Ruby 
about the language of Rails? Couldn't a similar framework be made for 
other languages, like Java for example, with similar results as Rails?

Also, from the article, I've identified two DSLs: SQL and rhtml (the 
equivalent of Java's JSPs). In both cases, Ruby code is generated from 
code in these two DSLs, but that code generation is performed not by the 
Ruby compiler during compile-time, but by an external tool (similar to 
parser generators for example). If so, that would be mean that the D 
1.005 features are not necessarily required or useful for the "enabling 
of such applications", which I think was the point kris was making in 
the Derailed DSL thread ago. Good interoping with DSLs is decisive, but 
that doesn't mean the interoping needs to be done at compile-time, by 
the compiler.
Is this correct?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D