The Active Record

nostalgicisolatedSoftware and s/w Development

Nov 4, 2013 (3 years and 9 months ago)


The Active Record

Databases in Database
Centric Web Site

Installing Ruby on Rails

Choice one: Do it yourself. Go to

and follow the instructions to
install Ruby, RubyGems, and Rails. It is very easy.

You will also need MySQL.

Installing RoR, cont.

Use a prefab version for Windows and Mac (there is also
a Linux version I have never used):

This gives you everything all at once.

be careful to give the installer an unused port for mysql
and for apache. If the defaults, 3306 and 80, are
already in use, pick other numbers.

This comes with the phpmyadmin web SQL gui.

Notes on Ruby on Rails

Ruby on Rails has its own web servers that come with it,
so you don’t need Apache, but bitnami does install

Ruby on Rails will work with lots of DBs, and in fact, one
of the goals of RoR is to give DB independence

The default port for a RonR app is 3000, but you can tell
it to use others; generally, you use 3000, 3001, 3002, ...

Web Development

Moving the focus from web page design to website

All in one approach

Build in MVC approach: model (db), view (html pages),
Controllers (scripts)

Use one perspective for building all components; in
particular, use a consistent syntactic approach for
Controllers, DB interactions, etc. No SQL syntax


if you use RonRails


The model is the state of the application

The views are what the user sees and manipulates

Controllers know how to translate between the two

The MVC paradigm is very old and predates modern
based displays and were originally used to model
very rudimentary forms of user input.

The Big Issues

SQL is a declarative, set
oriented language tied to the
relational or object
relational model. SQL manipulates
sets of tuples.

Applications tend to be written in procedural, often object
oriented languages

So, to bridge

the semantic gap...

First, we use “lowest common denominator” semantics:
the database must pass single fields of single tuples to
the application

Second, the application must pass the database tuples,
and not objects

Two Choices

First, we could require that the application perform this
“mapping” each time

Or, we could have the application adopt a limited record
model that coincides with the relational model

This is sometimes called “wrapping”

We call this the Active Record paradigm

We manipulate active records in the application and
not in the db


This is not as much of a benefit as you might think,
because the manipulations that we perform on active
records look a whole lot like SQL

We still do not have a data model that coincides with the
application language, which in this case is Ruby, an
oriented scripting language

Other Properties

of Active Records

The focus is on convention and not configuration; thus, to
get the controllers (application) to talk to the models
(active records are automatically mapped to tables), we
only need to specify a few pieces of information

A key assumption behind this approach is that relational
database management systems are here to stay

How Active Objects

are Manipulated

Database tuples are a silent, persistent store that serves
only to record the state of the application; it is not the
data workspace

Active Records are created by the application

The application assigns/reads/updates the attributes of
Active Records

The Active Record is mapped to a tuple in a table in the

But, to maintain the integrity
of the persistent store...

There are explicit commands to delete records from the
database itself, and is not a side
effect of deleting an
Active Record, so the application programmer must be
aware of the database

Transactions must also be used, for the same reason

The “Convention” Approach

in Ruby on Rails

A table name is the plural form of the name of a
corresponding Active Record class

Table names are in lower case

Table names consist of one or more character strings;
the strings are connected by underscores, but in a class
name, the words are run together and the words are

e.g., MyItem, my_items.


Putting objects in the database

Using more than one database

Using legacy databases

Centric Apps

This has been a contentious issue over the decades, and
at one point, “process
centric” was considered the only
intelligent way to build information
intensive systems,
whether they are desktop, web
based, or distributed

But now, the database is back in focus.

Ironically, at the same time, we are hiding the db

This creates a more unified syntax, limits configuration

It also makes it easier to make db schema changes


Other DBs

you can use with RonR

MySQL, Firebird, DB2, Postresql, Oracle, Openbase,
Sybase, SQLite, SQL Server

SQLite is a single file and very easy to install and use,
but the last I used it, no FKs.

Openbase is used heavily by applications that need to
store data.

CRUD: Abstracting the DB

Each table corresponds to a subclass of

Create rows, reading rows, updating rows, deleting rows

These update active records, not the db directly


There is a transaction method is used to execute a block
of code

Ar_name.transaction do...end

Ruby on Rails Overview

Ruby on Rails uses the MVC paradigm

Models: Active Records/Relational tables

Views: HTML with embedded ruby and data from db

Controllers: Ruby programs

What’s in a Ruby on Rails

A set of embedded folders with the skeleton of a Web
application already in place

That application will be available via a browser and a


One of the sub
folders in our project will be “script”

in that is a ruby program called “server”, which starts the
app talking to port 3000 on localhost

The Folders Within

a RonR Application

app: views, controllers, models

components: self
contained applications (with all MVC

db: scripts that maintain the db, as well as sqlite dbs

doc: you can automatically create code for your app

Folders, cont

log: for development, testing, production

public: holds standard web files, for style sheets, etc.




routes.rb (routing of incoming requests from the web)

Folders, cont.

test: unit tests and such

vendor: libraries from vendors, that do such things as
maintain security

script: programs that run various parts of your application
and tools that you use while you are building your app

generate (various pieces of scripting, html code, for
things like controllers and scaffolding etc.)

server (web)

Key Concepts

All in one environment for life
cycle of a web app that
minimizes configuration

Large grained design philosophy (MVC)

Generating code

Scaffolding to build overall skeleton of the app, pre

but much of this is meant to be temporary

Managing the db the way you manage the rest of the app


One db, unless you play some tricks

but you get some richer modeling capabilities

Very rigid overall architecture of your app

Somewhat hard to plug in other scripting languages

If you want to use outside components, like apache or
coldfusion, you have to do some configuring

Migrations:Providing Near
Uniform DB Management

You use it from within Rails to build database

Two things are done outside RonR

Creating the db itself, more or less just giving it a name

Putting test data in the db to test your app

Macintosh:projects kingbuzz$ rails expenses


create app/controllers

create app/helpers

create app/models

create app/views/layouts

create config/environments

Macintosh:projects kingbuzz$ mate expenses