RoR, Judge Judy, and little old ladies

[Andrei Alexandrescu (See Website For Email)]

Bruno Medeiros wrote:
> 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?
> 

That is correct. But everybody is doing the run-time schtick, so doing 
it during compilation would bring an edge (error detection and faster 
execution).

Andrei