CSC/ECE 517 Fall 2010/ch3 3j KS

Introduction

Object-relational mapping (ORM) provides developers with a set of tools that ease management of the relationships between objects and relational databases, thus allowing applications to be easily extended to add data persistence. For Ruby, several object-relational mapping options are available in addition to ActiveRecord, the ORM layer supplied with Rails.

Overview

Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:

• Automatic mapping from classes to database tables
  • Class instance variables to database columns
  • Class instances to table rows
• Aggregation and association relationships between mapped classes are managed
  • Example, :has_many, :belongs_to associations in ActiveRecord
  • Inheritance cases are mapped to tables
• Validation of data prior to table storage
• Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
• Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

When applied to Ruby, implementations of ORM often leverage the language’s metaprogramming strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality.

Comparison of ORM products for Ruby

ActiveRecord

ActiveRecord, originally created by David Heinemeier and released in 2003, became the de-facto ORM for Ruby since it was integrated in the widely-used Rails framework, however alternate ORMs for Ruby have been developed and Rails 3.x is ORM independent. ActiveRecord is an implementation of the active record design pattern, where a table is wrapped into a class and this class implements accessor methods for each column in the table. [1]

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:

class CreateUsers < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.string :name
      t.string :email
      t.integer :age

      t.timestamps     # add creation and modification timestamps
    end
  end

  def self.down        # undo the table creation
    drop_table :users
  end
end

Note in the preceeding example, that the ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’to_many’’ association with both the cheers and posts tables. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

class User < ActiveRecord::Base
  
  has_many :cheers
  has_many :posts
  
  validates_presence_of :name
  validates_uniqueness_of :name
  validates_length_of :name, :within => 3..20
end

While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design.

Pros -

• Integrated with popular Rails development framework
• Dynamically created database search methods (eg User.find_by_address) ease db queries and make queries database syntax independent
• DB creation/management using the migrate scheme provides a means for backing out unwanted table changes

Cons -

• DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application

Sequel

Sequel was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.16.0. Initially Sequel was had three core modules - sequel, sequel_core and sequel_model.Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

Some of the key features of sequel are,

• Connection Pooling
• Thread Safety
• Eager Loading / Lazy Loading
• Model Caching

class CreateUser < Sequel::Migration
  def up
    create_table(:user) {
      primary_key :id
      String :name
      String :password }
  end
  def down
    drop_table(:user)
  end
end # CreateUser.apply(DB, :up)

DataMapper

http://www.gelens.org/2007/12/13/ruby_orm_datamapper/ Ruby ORM: DataMapper There is a relative new ORM (Object Relational Mapper) for Ruby called “DataMapper”. Its goal is to create a fast, feature rich and thread-safe(!) ORM. DataMapper can be used standalone or as plugin for example Rails or Merb. Finally some competition in the Ruby ORM world. Rails’ ActiveRecord is no longer the only usable production ORM. DataMapper’s developers made some radical different fundamental design decisions regarding to migrations and property declarations. Property declarations are now done in the Model itself and not in separate “migration”-files. Which is more elegant in my opinion. Lately DataMapper is growing fast, it gets more attention and its feature list gets longer and is already superior to AR in terms of speed. A few weeks ago I started a new project using the new ruby framework Merb. Merb is also thread-safe and is in combination with DataMapper a really cool framework. By the way, did you know Rails is not thread-safe? Kinda sucky for a web framework to handle only one connection at a time. That’s the reason why people use multiple Mongrel servers when deploying Rails application. Not everyone I know seems to realize that. The bad thing is, there is NO plan to make it thread-safe :-/. [2] DataMapper: A Better ORM for Ruby One of the things that’s always irritated my about rails’ ActiveRecord framework is the way that the domain model lives in the database.Don’t get me wrong: it’s very clever, and a great showcase for ruby’s metaprogramming features, which will blow average C# / Java mind the mind when they first see it. In rails, you build a database of your domain model, and create empty classes with the names of the domain entities (conventionally the singular of a database table name) which inherit from ActiveRecord. ActiveRecord then looks at your database, and using the magic of metaprogramming, hydrates your object with a bunch of properties that map to the database fields. But I prefer to write my models in the code, and if you do too, you might want to take a look at DataMapper.

Comparison of ORM Features

Features	ActiveRecord	Sequel	DataMapper
Databases	MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2	ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3	N/A
Migrations	Yes	Yes	No
EagerLoading	Supported by scanning the SQL fragments	Supported using eager (preloading) and eager_graph (joins)	N/A
Flexible Overriding	No. Overriding is done using alias methods.	Using methods and by calling 'super'	N/A
Dynamic Finders	Yes. Uses 'Method Missing'	No. Alternative is to use <Model>.FindOrCreate(:name=>"John")	N/A

Conclusion

Ruby ORM bla.

References

[1] Ruby language

[2] Fowler, C., The Ruby FAQ, www.rubygarden.org/faq

[3] , Active Record — Object-relation mapping put on rails, http://ar.rubyonrails.org/

External Links

1. WxRuby
2. ActiveTcl for Windows