In a recent series of articles, you learned how to set up a proof of concept for an online bookstore created using Ruby-on-Rails. In this four-part article series, you'll start creating the application for real, using test-driven development. This article is excerpted from chapter two of the book Practical Rails Projects, written by Eldon Alameda (Apress; ISBN: 1590597818).
Author Management for an Online Bookstore - Editing the Migration File (Page 4 of 4 )
The next step is to open the migration file in a text editor and edit it so that the database will look how we want it to look. In this case, it means adding two fields to the table skeleton:
class CreateAuthors < ActiveRecord::Migration def self.up create_table :authors do |t| t.column :first_name, :string t.column :last_name, :string end end
def self.down drop_table :authors end end
Rails migrations use a special domain-specific language (DSL) written in Ruby. This way, the migration code is database-agnostic and can be used to deploy the application to different database platforms.
Every migration should implement the methodsself.upandself.down, which are created automatically when a new migration is generated by running either thegenerate modelor the explicitgenerate migrationcommand. Code insideself.upis run when the database is migrated to a higher version, and the code inself.downis run when the database is migrated back to an earlier version. In our first migration, we create a new table calledauthors and add columns for both the first and last names of an author. In theself.downpart, we drop theauthors table, just in case we someday would want to go back to ground zero.
Note Even though every table used by ActiveRecord (except for join tables) should have a primary key field calledid, we didnít specify the creation of that column in our migration. This is because Rails will automatically create that field for every table, unless you explicitly tell it not to by using the:id => falseoption withcreate_table.
The commands in the migrations DSL mostly match the corresponding SQL statements. The following are the most commonly used commands. For complete documentation, see the Rails API documentation for migrations athttp://api.rubyonrails.org/classes/ActiveRecord/ Migration.html.
create_table(table_name, options): Creates a new tabletable_name. If it is given a block parameter (as in theCreateAuthorsmigration shown in the previous section), the commands inside the block will be executed inside the scope of this table.
column(column_name, type, options): Creates a new columncolumn_nameof typetypein the scope of enclosingcreate_tableblock.
add_column(table_name, column_name, type, options): Equivalent tocolumn, with the distinction that it is not used inside acreate_tableblock, and thus needs the name of the table as an argument.
drop_table(table_name): Drops the tabletable_namefrom the database.
Please check back for the next part of the series.
DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.