The Active Record Paradigm Databases in Database-Centric Web Site Development

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 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: ❖ or ❖ 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