December 10, 2017
Hot Topics:

Meet DataMapper ORM, the Unified Ruby Interface for Data Stores

  • October 18, 2011
  • By Jason Gilmore
  • Send Email »
  • More Articles »

The ability to stay "in the zone" is a crucial characteristic of any productive developer, with the tiniest distraction capable of making mincemeat out of an otherwise successful workday. The oft-discussed distraction is external, the result of an unusually talkative colleague or passing fire engine. However, internal distractions are equally plentiful. One of the most notable distractions occurs when the developer is forced to interweave multiple libraries together, with each offering its own syntactical quirks.

Consider for instance an application which communicated with multiple data sources, including a MySQL database, Facebook, and an IMAP store. Typically the developer will identify the best third-party libraries which interact with these data sources, and then spend a good deal of time becoming familiar with their respective interfaces.

Many object-relational mapping (ORM) solutions effectively remove the need to familiarize oneself with multiple database-specific libraries, thanks to the ability to interact with most mainstream databases via a unified interface. However, the developer is still left with sorting out how to most effectively interact with non-relational database data stores. A great Ruby library called DataMapper is removing this delineation by offering a unified interface for a wide variety of data stores, including not only MySQL, PostgreSQL and SQLite, but also Facebook (via FQL), the Salesforce API, and Amazon S3. Once installed, Ruby developers can effortlessly plug into these data sources and more without having to tediously brush up on incongruent library interfaces.

In this article I'll introduce DataMapper by showing you how to integrate it into a Sinatra application. Even if you're not familiar with Sinatra, the Ruby code demonstrated throughout will be simple enough for even a beginning Ruby programmer to follow along just fine.

Installing DataMapper

DataMapper is available as a Ruby gem, meaning you can install it using RubyGems:

$ gem install data_mapper
Fetching: data_mapper-1.1.0.gem (100%)
Successfully installed data_mapper-1.1.0
1 gem installed
Installing ri documentation for data_mapper-1.1.0...
Installing RDoc documentation for data_mapper-1.1.0...

After installing DataMapper, you should install a database adapter. More than 30 adapters are available; see the DataMapper wiki for a complete list. For the purposes of this article I'll install the MySQL adapter:

$ gem install dm-mysql-adapter
Fetching: dm-mysql-adapter-1.1.0.gem (100%)
Successfully installed dm-mysql-adapter-1.1.0
1 gem installed
Installing ri documentation for dm-mysql-adapter-1.1.0...
Installing RDoc documentation for dm-mysql-adapter-1.1.0...

Of course, you'll additionally need access to a MySQL server in order to follow along with these examples.

Creating a DataMapper Model

DataMapper interacts with a resource's underlying data via a model, which allows you to neatly separate data-specific functionality from the rest of the application. Suppose we wanted to use the fantastic Sinatra framework in conjunction with DataMapper to create a Web application which managed our video game library. The games table schema which will contain the games looks like this:

mysql>CREATE TABLE games (
  name VARCHAR(255) NOT NULL,
  platform VARCHAR(10) NOT NULL,
  created_at DATETIME NOT NULL

But rather than separately create and manage the table schemas, you can rely on DataMapper's built-in schema migration features to perform the manual labor for you (you will however need to create the database used to store the tables). After creating your project directory, create a directory named models which resides in the project directory, and within the models directory create a file named Game.rb:

class Game
  include DataMapper::Resource

  property :id, Serial
  property :name, String
  property :platform, String


This simple model defines a primary key named id, and two additional string-based properties named name and platform. Although it looks like any other class, DataMapper will know to treat it differently because of the reference to DataMapper::Resource.

With the model defined, create an app.rb file in your Sinatra project directory, and add the following contents to it:

require 'rubygems'
require 'sinatra'
require 'data_mapper'
require 'erb'

# Include the models
require 'models/Game'

# Connect to MySQL
DataMapper.setup(:default, "mysql://user:password@localhost/dev_gamelibrary")

# Make sure the database tables match the models

Next, fire up the Sinatra app per usual:

$ ruby app.rb
== Sinatra/1.2.6 has taken the stage on 4567 for development with backup from Mongrel

The Game model will be parsed and a corresponding table named games created within the database, or modified to match the latest version of the Game model:

mysql> describe games;
| Field    | Type             | Null | Key | Default | Extra          |
| id       | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| name     | varchar(50)      | YES  |     | NULL    |                |
| platform | varchar(50)      | YES  |     | NULL    |                |

Try making changes to the model and restarting your Sinatra application; you'll see the changes transparently propagate to the games table!

Incidentally, integers and varchar-based strings are only a few of many data types supported by DataMapper. Additionally, it's easy to tweak properties to override defaults such as the 50-character VARCHAR limit used in the games table. See the DataMapper documentation for all of the details.

Originally published on https://www.developer.com.

Page 1 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date