Database Tables, Controllers for Ruby-on-Rails Applications

Database Tables, Controllers for Ruby-on-Rails Applications
(Page 1 of 2 )

Creating a Database Table

We need to create a table in the database. We could do this with a database administration tool, or even manually using SQL, but Rails provides a much more efficient facility for table creation and maintenance called migrations. It’s called a migration because it allows you to evolve, or migrate, your schema over time. (If you’re not familiar with databases, tables, and SQL, consult Appendix B for the basics.)

Schema is the term given to the properties that make up a table: the table’s name, its columns, and column types, as well as any default values a column is to have. And what’s the best part about migrations? You get to define your schema in pure Ruby. This is all part of the Rails philosophy that you should stick to one language when developing. It helps eliminate context switching and results in higher productivity.

As you can see from the output of the model generator, it created a new file indb/migratecalled001_create_events.rb. Notice that migrations are named with a numeric prefix, starting at 001. Since migrations are run sequentially, this number represents their position in the queue.

Let’s open this file and take a peek. It’s shown in Listing 3-2.

Listing 3-2. The db/migrate/001_create_events.rb File

class CreateEvents < ActiveRecord::Migration
  def self.up
    create_table :events do |t|
    end
  end

  def self.down
    drop_table :events
  end
end

In its initial, generated form, the migration is a blank canvas. But before we go any further, let’s note a few important items. First, notice the class methods:upanddown. For each migration, you define instructions for updating in theupmethod, and use thedownmethod to roll back any changes. So, if you were to, say, create a new table in theupmethod, you would drop the table in thedownmethod, thereby reversing your changes. In fact, that’s exactly what the generator did for us already: Theeventstable gets created onupand dropped ondown. Pretty slick, isn’t it?

Note  You can easily spot the difference between class and instance method definitions in a Ruby class by looking for theself prefix. For more about Ruby classes, see Appendix A.

We’ve gone ahead and filled out the details for you. Without having seen a migration before, you should be able to tell exactly what’s going on by looking at Listing 3-3.

Listing 3-3. Completed db/migrate/001_create_events File

class CreateEvents < ActiveRecord::Migration
  def self.up
    create_table :events do |t|
      t.column :title,     :string 
      t.column :location,  :string 
      t.column :occurs_on, :date
    end
  end

Let’s step through the code. First, we use thecreate_tablemethod, giving it the name of the table we want to create. Inside the code block, we use thecolumnmethod to create columns in the table. Thecolumnmethod takes the name of the column and its type. (For a full description of the available field types you can create in your migrations, seehttp://api.rubyonrails.org/classes/ActiveRecord/ Migration.html.)

On its own, this migration does nothing. Really, it’s just a plain-old Ruby class. If we want it to do some work and create a table in the database for us, we need to run it. To run a migration, you use the built-in Rake task that Rails provides calleddb:migrate.

Note  Rake is a build language for Ruby. Rails uses Rake to automate several tasks, such as running database migrations, running tests, and updating Rails support files. You can think of Rake tasks as little utility programs. For a list of all available Rake tasks, runrake -Tfrom your Rails project directory. For more information about Rake, including complete documentation, seehttp://rake.rubyforge.org/.

From the command line, type the following to run the migration and create theeventstable. You’ll recognize this command as the same one we used to test the database connection. We sort of hijacked it for our test, knowing that it will attempt to connect to the database and thus prove whether the connection works. Since there were no existing migrations when we first ran it, it didn’t do anything. Now that we have our first migration, running, it will result in a table being created.

$ rake db:migrate

--------------------------------------------
== CreateEvents: migrating ================================================== -- create_table(:events)
   -> 0.0314s
== CreateEvents: migrated (0.0316s) =========================================
--------------------------------------------

Just as the output says, the migration created a new table. If you were to try to run the migration again (go ahead, try it!), you would see that nothing happens. That’s because Rails keeps track of the current migration version and it knows that you’re at version 1, so there’s nothing left to do.

blog comments powered by Disqus