|
|
| Line 1: |
Line 1: |
| A Database is a coherent collection of data with inherent meaning. Random assortment of data is not a database. Data is organized in order to model relevant aspects of reality, so that it supports processes requiring this data.
| | ==Introduction== |
| Data Migration is related to transfer of data between storage types, formats, or computer systems. This is performed programmatically to accomplish an automated migration so that humans are free from doing this repetitive task.
| | ramya |
| | | ==bhavin== |
| Content:
| | hi |
| | |
| Database : A database is nothing more than a collection of meaningful information. Databases can be of multiple types, for example Distributed Databases, Relational Databases, Flat File Databases. A database could be as simple as a text file with a list of names or it can even be very complex as a large relational database management system
| |
| 1. Banking Systems where accounts are maintained and it is made sure that money does not disappear as a result of system failure.
| |
| 2. Airline Reservation Systems where the plane details, the airport details and the customer details are maintained.
| |
| 3. Hotel Management Systems where the availability of rooms, the rates and the customer details are maintained.
| |
| (Figures: RDBMS of a Bank)
| |
| | |
| | |
| Every application in reality has a database in the backend to store all the relevant data of the application. We should not test the application on database because it may contain valuable data like customer information in a banking system. So editing that data present in the database is not a good idea. The solution Rails provides for above problem is Defining three different environments: Development, Production and Testing each of which has a separate database and appropriate database types.
| |
| The Development Environment is what we use while developing the application. The production environment refers to the database that is used when the application is published in the real world. The testing environment is meant for testing tools. Testing of the application is done using Testing tools which automates the entire testing procedure. Since there are different databases in each environment, the problem that occurs is changes made in one Database do not reflect in the other.
| |
| A programmer is also responsible to tell the other developers what changes have been made in the database. Also one has to keep track of which changes need to be run against production machines during deployment.
| |
| | |
| The solution for the above problem that rails offers is Database Migration. Databases of different types can also be migrated between the three different environments. For example, we may use SQLlite in Development environment, but we can still migrate into production environment where heroku may have been used. The source is portable and the backend understands what operations to do on the database.
| |
| | |
| In reality Rails migrations are similar to version control of databases. Rails migrations is actually used since databases change requires modifications to both code and data. Hence we cannot use a source code version control system like Subversion or Sourcesafe.
| |
| | |
| Advantages of Migration:
| |
| 1. You can identify each migration and know when it has taken place.
| |
| 2. Some migrations can also be rolled back. We can specify what the roll back procedure is.
| |
| 3. Migrations can be managed with version control.
| |
| 4. Automation – Automate things to be done which makes it reliably repeatable. For example, In Ruby on Rails, we use Bundler instead of installing all gems manually. In short, specify what needs to be done and automate it.
| |
| | |
| Creating A Migration:
| |
| A migration is a sub class of ActiveRecord:: Migration which implements two methods: ‘up’ and ‘down’. The “up” method performs the required changes or transformations while the down methods reverses or roll backs them.
| |
| A migration can be created using the following command:
| |
| rake generate migration CreateCourse
| |
| Migration Created :
| |
| | |
| class CreateCourse < ActiveRecord::Migration
| |
| def up
| |
| create_table :course do |t|
| |
| t.string :name
| |
| t.text :description
| |
| t.timestamps
| |
| end
| |
| end
| |
| def down
| |
| drop_table :course
| |
| end
| |
| end
| |
| | |
| The above migration CreateCourse has just been created, but has not been applied to the Database yet. This migration will add a table called courses with string column called name and the text column called description. A primary key column called id will also be created by default. The time stamp columns created_at and updated_at which ActiveRecord populates automatically will also be added. Reserving this migration is nothing but dropping the table
| |
| | |
| Migrations can also be used to fix bad data in the database or generate new fields. For Example,
| |
| | |
| class AddGradesToStudents < ActiveRecord::Migration
| |
| def up
| |
| change_table :students do |t|
| |
| t.boolean :receive_grade, :default => false
| |
| end
| |
| User.update_all ["receive_grade = ?", true]
| |
| end
| |
| def down
| |
| remove_column :students, :receive_grade
| |
| end
| |
| end
| |
| | |
| The above migration adds receive_grades to the students table. We want the default value to be false for new students. But existing students are considered to have a grade, So we use the student model to set the flag to true for existing students.
| |
| | |
| Active Record provides methods that perform common data definition tasks in a database. A migration is like a Ruby class so you’re not limited to these functions. For example, after adding a column you can write a code to set the value of that column for existing records (if necessary using your models).
| |
| Where are migrations stored:
| |
| Migrations are stored as files in the db/migrate directory, for every migration class. The name of the file is of the form YYYYMMDDHHMMSS_create_course.rb, that is nothing but a UTC timestamp identifying the migration followed by an underscore followed by the name of the migration.
| |
| Changing Migrations:
| |
| If you wish to make changes to the migration and you have already run the migration then you cannot just edit the migration and run it again. Rails will consider ir has already run the migration, so it will do nothing on running “rake db:migrate”. The migration has to be rolled back and then make changes to the migration and run it.
| |
| It is not recommended to edit existing migration and that too if it has been run on production systems. Instead, writing a new migration that performs the changes required is better. Making changes to a newly generated migration that has not been committed to source code is relatively safe.
| |
| Relationship between model and migration:
| |
| In Rails, a model internally maps itself to a database table. The table in the database must be the plural form of the model’s class. If we generate a model called Course, Rails automatically looks for a table called courses in the database.
| |
| You can use the Rails generator to generate both the model and a corresponding migration using the following commands:
| |
| rake generate model Course name:string description:text
| |
| will create a migration that looks like this
| |
| class CreateCourses < ActiveRecord::Migration
| |
| def change
| |
| create_table :courses do |t|
| |
| t.string :name
| |
| t.text :description
| |
| t.timestamps
| |
| end
| |
| end
| |
| end
| |
| Creating a standalone migration:
| |
| If you are creating migrations for other purposes, then a migration generator is used:
| |
| $ rails generate migration AddSemesterToCourse
| |
| This will create an empty but appropriately named migration:
| |
| class AddPartNumberToProducts < ActiveRecord::Migration
| |
| def change
| |
| end
| |
| end
| |
| | |
| Applying Migration to Development:
| |
| Since CreateCourse migration has been created but not applied to the database, the following command is used to apply the migration to the development database:
| |
| rake db:migrate
| |
| | |
| Applying Migration to Production:
| |
| The following command is used to apply migration to the production database:
| |
| heroku rake db:migrate
| |
| In the above example the production database is Heroku
| |
| | |
| | |
| Rolling Back a migration:
| |
| The following command is used to rollback the last migration:
| |
| rake db:rollback
| |
| Rollback is performed when you made some mistake and instead of tracking down the version number of the previous migration, you can just rollback and run it after making changes.
| |
| If you need to rollback several migrations, a STEP parameter is used. For example,
| |
| rake db:rollback STEP=2
| |
| The above command will rollback the last 2 migrations.
| |
| The db:migrate:redo task is an easy way for doing a rollback and then migrating again. If you need to redo several migrations, a STEP parameter is used. For example, in order to redo the last 4 migrations, the command is
| |
| rake db:migrate:redo STEP=4
| |
| “rake db:reset” is the command for resetting the database. This will drop the databse, recreate it and loads the current schema into it.
| |
| 4.3 Running specific migrations
| |
| If you need to run a specific migration up or down, the db:migrate:up and db:migrate:downtasks will do that on including the version also. For example,
| |
| rake db:migrate:up VERSION=20080906120000
| |
| The above command will run the up method from the 20080906120000 migration. These tasks still check whether the migration has already run, so for example db:migrate:up VERSION=20080906120000 will do nothing if Active Record believes that 20080906120000 has already been run.
| |
| Disadvantages of migrations:
| |
| 1. One drawback of Rails migrations is that all migrations occur at the database level, not the table level.
| |