So let's talk about the type of system we want to create with out Rails prototype. Being ever so popular, it may be fun to start with a WIKI. Our basic WIKI required the ability to easily create, read and update web pages. We will want a custom look and feel, as well... which will have us diverge from the basic scaffolding of rails, which you will see in a moment. Doing this, you will see how Rails is customizable to meet your individual needs of navigational workflow.
Our WIKI should allow us to create pages, and track the revision history of the page as edits are made. The figure below shows the data model. We will have a table named PAGES which will contain a single record for each page on the WIKI. However the PAGES table will not contain the content of the page. Instead, the content of the page will be stored in a child table named REVISIONS. This is due to the fact that we wish to historically track content as it is edited.

Rails has included with it a mechanism for change control of the database schema known as Migrations. Migrations store meta data about the current schema in the database, allowing for rollback and commit of sql migrations much like you would be expecting of your source code in a repository such as Subversion of CVS.
We will now create the migration for the two tables above. Type in the following command, from the newly expanded rails project you created
ruby script/generate migration wiki
This command fill first create the db/migrate directory, since it does not exist... then it will create a .rb Ruby file in the db/migrate directory with a timestamp, followed by the description we wrote on the command ("wiki").
Inside you will find a class with two methods contained within it. For basics, the self.up method will be the method in which we will be creating the tables, and the self.down is where we will code the functionality which should be executed if this migration was to be undone.
class Wiki < ActiveRecord::Migration
def self.up
create_table :pages do |t|
t.string :name
t.timestamps
end
create_table :revisions do |t|
t.integer :page_id
t.text :content
t.timestamps
end
end
def self.down
drop_table :pages
drop_table :revisions
end
end
The code above creates the two tables described in the database diagram shown above. The t.timestamps command will automatically create the created_at and updated_at columns, and the Rails migrations will automatically create an id column for each table.
Now that we have our database schema coded in our migration file, we can execute the migration to have it applied to the physical database. Since we installed SQLITE in a previous blog entry, our database is already setup and ready to go. Run the migration with the following command in the root of your rails project:
rake db:migrate
While we will wish to customize our Rails application, you will be able to quickly enjoy some fruits of your labor by utilizing the scaffolding functionality built into Rails. The scaffold with create the shell of your application, giving you basic CRUD capabilities.
Scaffold the 'pages' table by performing the following command in your project's root directory:
ruby script/generate scaffold pages name:String
This will create a controller, model, view and test for the 'Page' object, and the views will contain the 'name' parameter for the user to manipulate and store. Run the server:
ruby script/server
And then point your browser to http://localhost:3000/pages to enjoy your working app. In the next portion of this tutorial, we will customize the app into a working WIKI.
Continued in Ruby on Rails for Architects #5 - A Working WIKI


