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