The Active Record

nostalgicisolatedSoftware and s/w Development

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

101 views

The Active Record
Paradigm

Databases in Database
-
Centric Web Site
Development

Installing Ruby on Rails


Choice one: Do it yourself. Go to
http://rubyonrails.org/down

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):


http://bitnami.org/stack/rubystack

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


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
Frameworks


Moving the focus from web page design to website
design


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


But


if you use RonRails

MVC


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
pixel
-
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

But...


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
object
-
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
database

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
capitalized:


e.g., MyItem, my_items.

Problems


Putting objects in the database


Using more than one database


Using legacy databases

Database
-
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




t

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
ActiveRecord::Base


Create rows, reading rows, updating rows, deleting rows


These update active records, not the db directly

Transactions


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
Application?


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
port:


http://127.0.0.1:3000

or
http://localhost:3000


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
pieces)


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.


config:


database.yml


environment.rb


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
-
configured
-

but much of this is meant to be temporary


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

Trade
-
offs


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
components


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


create app/controllers


create app/helpers


create app/models


create app/views/layouts


create config/environments

Macintosh:projects kingbuzz$ mate expenses