Meet DataMapper ORM, the Unified Ruby Interface for Data Stores
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.
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 ( id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, 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
class Game include DataMapper::Resource property :id, Serial property :name, String property :platform, String end
This simple model defines a primary key named
id, and two additional string-based properties named
platform. Although it looks like any other class, DataMapper will know to treat it differently because of the reference to
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 DataMapper.auto_migrate!
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
Game model will be parsed and a corresponding table named
games created within the database, or modified to match the latest version of the
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
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.