Getting Started With Ruby on Rails Models

by Erik Andrejko

In a previous article we introduced the Views and Controllers of the Ruby on Rails MVC architecture. In this article we will discuss the models, perhaps the most powerful part of Ruby on Rails.

Many web applications are in the large part interfaces to a back end relational database system. Relational database systems store data in rows in tables. In an object oriented system data is stored in objects. A tool that transforms rows in a relational database into objects is called an object relational mapper (ORM). The object relational mapper included as part of Ruby on Rails is called ActiveRecord. ActiveRecord associates each table in a relational database with a Ruby class. The corresponding class provides methods to update and query rows of that table. By implementing models using the ActiveRecord pattern, Ruby on Rails provides a powerful abstraction layer that decouples the web application for the underlying relational database mechanism.

To see how this works in practice let’s look at an example. Suppose we have a table of customers in relational database that looks like this:

+====+=============+============+================+
| id | contact_id  |    name    | phone_number   |
+----+-------------+------------+----------------+
| 23 | 254         |  Acme      | (555) 123-3333 |
| 24 | 265         |  Widgets   | (555) 323-3133 |
| 25 | 277         |  Booker    | (555) 725-3653 |
+====+=============+============+================+

The customers table can now be accessed via the Ruby Customer class using class and instance methods. For example:

customer = Customer.find(23)    
customer.name # => "Acme"
customer.phone_number # => "(555) 123-3333"

Every object of class Customer has methods that corresponds to the columns of the customers table. By using an ORM, it is possible to think of each table in the database as a list of objects and to ignore the underlying relational database architecture and query language.

Configuring the Database Connection

A Ruby on Rails application can be run in one of many environments that influence various parts of the framework. There are three standard environments:

• Development: for developing your application
• Testing: for running automated unit and integration tests
• Production: the deployed production version of your application

The database connection is configured separately for each Rails environment. That means that a separate database can used for each of the environments. The database configuration is stored in the config/database.yml file, which looks something like:

# SQLite version 3.x
#   gem install sqlite3-ruby (not necessary on OS X Leopard)
development:
  adapter: sqlite3
  database: db/development.sqlite3
  pool: 5
  timeout: 5000

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
  adapter: sqlite3
  database: db/test.sqlite3
  pool: 5
  timeout: 5000

production:
  adapter: sqlite3
  database: db/production.sqlite3
  pool: 5
  timeout: 5000

Most standard databases are supported by ActiveRecord including MySQL and PostgreSQL. The simplest database to use during development is the sqlite database, a flat file based database. If you don’t already have MySQL or PostgreSQL installed, install sqlite with:

sudo gem install sqlite3-ruby

To change any of the database connection details it is necessary to change both the adapter name and the other associated parameters that depend on the choice of database. For example to configure a connection to a MySQL database named customers_development:

development:
  adapter: mysql
  database: customers_development
  user: root
  password: 
  pool: 5
  timeout: 5000

You can verify that the database connection has been successfully configured by running the script/dbconsole command which will connect to the development database and display a terminal.

Routes and Controllers
Getting Started With Ruby on Rails Models
Creating Models