cfis : Making Rails Better - Fixing Architecture Flaws in Active Record

Comment on Making Rails Better - Fixing Architecture Flaws in Active Record by John

Sun, 12 Aug 2007 19:23:32 -0600

Yep, give it a few more versions and maybe AR will begin to measure up to some of the Perl ORMs from two years ago ;)

Comment on Making Rails Better - Fixing Architecture Flaws in Active Record by Jon

Sun, 12 Aug 2007 19:54:39 -0600

Would this break portability? One of the ‘cool’ things about rails seems to be that you can move it to another DB without breaking anything, the migrations should just automagically create the schema and you’re ready to roll.

That being said, breaking portability in order to use advanced DB features seems worth it to me. Migrations are cool, but quite simple in what they can do. (But, to support SQLlite, they sort of have to be)

Comment on Making Rails Better - Fixing Architecture Flaws in Active Record by Charlie

Sun, 12 Aug 2007 20:06:18 -0600

Hi Jon,

No, by default it wouldn’t break portability - its just a better way of packaging ActiveRecord’s existing code.

Of course if added your own custom data type, then it would be up to you to port it across databases if you needed database portability. But in reality, I think database portability is way over-rated. Its hard enough getting one database setup right, let alone several.

Comment on Making Rails Better - Fixing Architecture Flaws in Active Record by wilsonm@yahoo.com

Mon, 13 Aug 2007 09:25:46 -0600

Having real bind variables would also be a big win. They probably cause a larger amount of time spend waiting than anything else.

Does anyone know if/when they will be available?

Comment on Making Rails Better - Fixing Architecture Flaws in Active Record by Charlie

Mon, 13 Aug 2007 11:10:07 -0600

Wilsonm,

That’s good point - its another place where ActiveRecord could be significantly improved.

Comment on Making Rails Better - Fixing Architecture Flaws in Active Record by topfunky

Tue, 14 Aug 2007 15:14:49 -0600

ActiveRecord is the largest library in Rails. Any increased efficiencies in the library would definitely help Rails applications in general.

I’d love to see a prototype that uses some of these ideas. It might break some third-party plugins but could be well worth the work to update them.

http://geoffreygrosenbach.com/system/assets/1144684900_normal.png

Comment on Making Rails Better - Fixing Architecture Flaws in Active Record by Crescent Fresh

Wed, 15 Aug 2007 08:10:11 -0600

So how would one go about mapping a db field to a column object (TimeColumn, FloatColumn, etc)? Would there still not be a need for a big case statement? Eg

def klass
  case type
    when :float     then FloatColumn
    when :datetime  then TimeColum
    # ...
  end
end

Comment on Making Rails Better - Fixing Architecture Flaws in Active Record by Charlie

Wed, 15 Aug 2007 11:58:34 -0600

Hi Crescent Fresh,

Depends at which point you mean. What I mean is:

Have a hash table per adapter class that is keyed on column type (a string, defined by the current database) with values being the correct Ruby column class for that type (you of course have to implement these classes). So:

mappings = {‘varchar’ => StringColumn,

'integer' => IntegerColumn,
'geometry' => GeometryColumn}

At startup, read data dictionary info from database to get list of columns (Rails of course already does this).
For each column, look up the Ruby column class in the hash table setup in #1. Create an instance of the ruby column object. Store it in another hash table, called columns, keyed on the column name. So each table has a columns hash table.

You’ve now avoided all case statements, so the code will be faster. And its easy to extend - a developer could just add a new mapping to the hash table defined in part #1.

Does that help?

Comment on Making Rails Better - Fixing Architecture Flaws in Active Record by Crescent Fresh

Thu, 16 Aug 2007 09:17:49 -0600

So you’ve replaced case statements with a hash table, correct? And this allows easily and elegantly adding custom column types. Agreed. Are hash table lookups really faster than case/switch statements though (in any language)? Less code, sure, but faster?

Comment on Making Rails Better - Fixing Architecture Flaws in Active Record by Charlie

Thu, 16 Aug 2007 10:35:15 -0600

CrescentFresh,

Sort of. Use a hash table to create the right column objects, and then just use inheritance/duck typing from there. Each column would have an api like:

def serialize end

def unserialize end

As far as hash lookups versus case statements in an interpreted language like Ruby, its hard to tell. Depends on the length of the case statement, and what code it executes. Either way, I wouldn’t imagine one to be much faster than the other. The equation changes for a compiled languages of course, but that’s not the issue here.