RoR, Judge Judy, and little old ladies

[Robby]

comments inline
Andrei Alexandrescu (See Website For Email) wrote:
> Robby 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 
snipped
>>
>> 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.
> 
> Makes sense. So if all Ruby does is e.g. display a column, which I 
> assume is a generic operation with uniform syntax over all types, the 
> type of that column could be anything. If, on the other hand, Ruby does 
> some math against a column, and that column changes from number to 
> string, runtime errors would ensue.
> 
Exactly, access is transparent as long as you don't use it as the 
previous type.

> What if there is a web page that accepts that column? Say the old type 
> was a string (so the appropriate form field is a textbox), and the new 
> type is a date (so the appropriate form field is three drop-down boxes). 
> Is Ruby's HTML generator going to figure things out and spit the 
> appropriate HTML page?
> 

It actually uses a form of template language, so any logic that depends 
on a certain type in the view would also need to adapt to the new logic.

>> 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.
> 
> Alright. And are there any operations (e.g. "print all columns") that 
> will naturally encompass the new column too?
> 
Yeah, you can get a hash of all columns, and you can access it via its 
property as aforementioned.

>> 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.
> 
> Interesting. So here's a limitation that might be addressed. Do all of 
> today's database engines (e.g. mysql) offer structure inspection (e.g. 
> "enumerate tables in this database", "enumerate fields in this table"...)?
> 
Though there may be some slight differences between what you *can* get, 
  I'm fairly sure that most/all databases have a metadata implementation.

>> 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
> 
> Interesting. I happen to disagree with the author, and the "you'll have 
> to pry that logic from my dead, cold object-oriented hands" part 
> definitely sets off a blinking red LED somewhere, but I'm not a DB 
> expert nor a Ruby expert so possibly I'm even misunderstanding things.
> 
I think they're taking a simplicity route when it comes to this (I can't 
read minds, but I'm assuming so) and there's some things I don't like 
about it either ~ namely you need to be explicit about validating a 
variable that the database provides you information for.

Example:
varchar with a length limitation of 255 characters and a default of 
"none". The length limitation and the default needs to be represented in 
the model class that represents the table, even though it's obvious that 
that validation should be generated as well (I mean, hello?).

Also of note would be using foreign keys to determine relationships. Of 
course this would need to be done in an delicate manner (that link has 
some pretty good ideas via foreign keys and determining relationships. 
RoR could take care of this information for you, but you have to 
explicitly state what you want to do (pros and cons of course)

> I'm not even thinking of stored procedures as logic vehicles. All stored 
> procedures I've dealt with were little more than simply stored views 
> (SELECT statements). If I want to see customer phone numbers and their 
> orders, I'm glad to let the database do that efficiently by doing an 
> inner join and passing me the information in one shot, instead of having 
> me look at the two relevant tables for the sake of object orientedness. 
> To say nothing about data integrity, which is best taken care of at the 
> database level.
> 
> The whole idea of manipulating data at table level and compulsively 
> delaying absolutely all meaning to the application level reminds me of 
> dBase and the 1980s.
Keep in mind that you can eager load other tables as you go through find 
methods, this allows you to either pull from the single table, or pull 
all related tables (while RoR writes an innner join behind the scenes)

> 
> Anyhow, what I think might be good for most people is to write a SELECT 
> statement that does something, and have the columns of that SELECT 
> automatically available for further processing. I understand RoR doesn't 
> do that.
> 
(not directly (that I recall), however you can define your own where 
clauses through the find methods generated on each model class.

There's some cool Ruby features that come into play during finders 
consider the following.
User.find_all_by_street_and_city(street, cities)
Ruby being dynamically typed has a method_missing function to all 
objects, if it's overrided any function calls that don't exist are 
routed though it, if it isn't an error is thrown.

The example above generates the where clause behind the scenes using 
that approach, lil tidbit :)
>> 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
> 
> Thanks, the answers were exactly to the point. By and large, I'm 
> interested in seeing strengths and limitations in the RoR approach, and 
> making an impression whether a more static approach would make a big 
> difference (better DB <-> code binding, better error detection, faster 
> execution).
> 
> After all, the approach wouldn't even feel much more static: with rdmd, 
> fast compilation, and the bang syntax, D can pretty much have the feel 
> of an interpreter.
> 
> 
> Andrei

And consider that Ruby *needs* to shovel a lot of work elsewhere for 
performance reasons first and foremost while D could, by design 
implement the whole stack. And honestly I can't think of any of the 
alternative frameworks that can truly say the same.

Some things about RoR make it interesting to work with, smart includes 
based on context (templates), smart template calling via the controllers 
actions, built in routing (kind of like url rewriting with the m,v,c's 
all considered. and conventions on column naming
created_on inserting a time when the model is first saved,
updated_on inserting a time when the object is resaved
built in support for nested tree models, lists, etc.

There's a lot of things they've gotten right, and while its obvious that 
performance wasn't the first thought, the idea of addressing performance 
as the concerns come in while having something implemented already is 
commendable (I've watched, and been a part of several things that are so 
performance inclined, it's never considered.. 1.0 ready).