Object-relational Mapping for Ruby

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. This wiki concentrates more on the comparison of ORMs and provides a high level overview of the top Ruby ORMs: ActiveRecord ,Sequel and DataMapper. It also includes a minor discussion on alternative frameworks that can be used either in place of or along with ORMs. These include the persistence framework iBATIS (more specifically the Ruby version RBatis), and the stack framework Merb.

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….

ORMs are crucial to almost any application that needs to access a database, as they provide the connection from the model of the program to the database itself. By enabling database rows to be used as objects, the program can more easily access and use the information in a way that is internally consistent and easy to understand. The ORM gives the programmer to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

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. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

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.

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.string :age
	  t.references :cheer
	  t.references :post

      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 an 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 ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. 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_presence_of :age
  validates_uniqueness_of :name
  validates_length_of :name, :within => 3..20
end

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes. 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. The following figure illustrates this concept of simplicity over efficiency.

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.44.0. Initially Sequel 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.

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

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute name.

class User < Sequel::Model
  one_to_many :cheers
  one_to_many :posts
  
  validates_presence [:name, :age]
  validates_unique(:name)
  validates_length_range 3..20, :name
end

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,

Connection Pooling
Thread Safety
Eager Loading / Lazy Loading
Model Caching

DataMapper

DataMapper is an open source ORM for Ruby originally developed by Sam Smoot and first released in 2007. DataMapper provides a very flexible mapping API which allows creation of adapters to a wide variety of datastores beyond traditional SQL-based relational databases – DataMapper adapters have been created to non-standard sources such as the Salesforce API and even Google Video.

Unlike ActiveRecord and Sequel, DataMapper does not rely on a migration scheme to create and manage DB tables. Instead, DataMapper allows table definition as part of the model class definition which keeps the model definition contained to a single file, thus minimizing the effort required to keep the database and model definitions in sync. When required, DataMapper can also support a migration methodology similar to other ORMs.

Example of table definition in the model:

class User
  include DataMapper::Resource

  property :id,         Serial    # key
  property :name,       String, :required => true, :unique => true     
  property :age,        String, :required => true, :length => 3..20 
  property :email,      String 
  
  has n, :posts          # one to many association
  has n, :cheers          # one to many association
end

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

Some of the key features of DataMapper are:

API supports a wide variety of databases, including non SQL types
Thread Safety
Eager Loading of child associations
Lazy loading
Works with or without a migration file.

iBATIS

iBATIS was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

RBatis is more lightweight than the other ORMs discussed so far. It provides a wrapper for SQL commands in Ruby, enabling one to call SQL with Ruby methods.

For instance, this code creates methods to find a user by ID and name.

Class User < RBatis::Base

  statement :select_one, :find do |id|
	["SELECT * FROM users WHERE id = ?", id]
  end
  
  statement :select_one, :find_by_name do |name|
    ["SELECT * FROM users WHERE name = ?", name]
  end
end

These methods can now be used as class methods.

User.find(1)
User.find_by_name('Bob')

Pros -

Enables direct use of SQL functionality within Ruby.
Is a thinner ORM than the others discussed.
Allows the programmer to create his or her own custom find methods.

Cons -

No longer supported
Database needs to be created/managed separately.
Standard find methods are not automatically created.

Merb

Merb was a model-view-controller framework created by Ezra Zygmuntowicz and released on November 7, 2008. It was a full-stack system like Rails, but only consisted of the core needed to create an application, leaving additional functionality to be installed by extra gems.
Merb is at 1.1, and will not have a v2.0 as it was absorbed into Rails 3.0 in 2008.

Merb itself provides only the controller of an MVC model, but this core is easily extended to create a full-stack application environment. In this sense, Merb itself is not an ORM, but it can easily accomodate any of the other ORMs described.

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	SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
Migrations	Yes	Yes	Yes, but optional
EagerLoading	Supported by scanning the SQL fragments	Supported using eager (preloading) and eager_graph (joins)	Strategic Eager Loading and by using :summary
Flexible Overriding	No. Overriding is done using alias methods.	Using methods and by calling 'super'	Using methods
Dynamic Finders	Yes. Uses 'Method Missing'	No. Alternative is to use <Model>.FindOrCreate(:name=>"John")	Yes. Using the dm_ar_finders plugin

Future Work

More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

CSC/ECE 517 Spring 2013/ch1 1d zk

Object-relational Mapping for Ruby

Contents

Introduction

Overview

ActiveRecord

Sequel

DataMapper

iBATIS

Merb

Comparison of ORM Features

Further Reading

Future Work

References

Navigation menu

CSC/ECE 517 Spring 2013/ch1 1d zk

Object-relational Mapping for Ruby

Introduction

Overview

ActiveRecord

Sequel

DataMapper

iBATIS

Merb

Comparison of ORM Features

Further Reading

Future Work

References

Navigation menu

Search