# Rails migrations--urgent

**URL:** <https://www.ruby-forum.com/t/rails-migrations-urgent/181151>\
**Category:** Rails\
**Created:** [January 6, 2010, 1:45pm UTC](https://www.ruby-forum.com/t/rails-migrations-urgent/181151 "2010-01-06T13:45:33Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![hitesh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/8e7dd6/32.png) [@hitesh](https://www.ruby-forum.com/u/hitesh)\
**Post date:** [January 6, 2010, 1:45pm UTC](https://www.ruby-forum.com/t/rails-migrations-urgent/181151/1 "2010-01-06T13:45:33Z")

</div>

Hello,  
I am new bee to Rails and I am really in a dilemma of follwing task:

I have some existing migrations and going to use some more new  
migrations, and I have few common fields which is not covered in my  
existing(old) migrations. Now I want some way to add this common fields  
with my existing as well as new migrations without writing any extra  
migration script.  
shall I need to use generators, if yes then how?  
also please let me know what is the best way to achieve this.

I will b e really thanful if someone could really help me out of this.

Waiting for reply

Regards,

Hitesh

---

<div class="post-metadata">

**Author:** ![hitesh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/8e7dd6/32.png) [@hitesh](https://www.ruby-forum.com/u/hitesh)\
**Post date:** [January 6, 2010, 5:24pm UTC](https://www.ruby-forum.com/t/rails-migrations-urgent/181151/2 "2010-01-06T17:24:45Z")

</div>

Hitesh R. wrote:

> I have some existing migrations and going to use some more new  
> migrations, and I have few common fields which is not covered in my  
> existing(old) migrations. Now I want some way to add this common fields  
> with my existing as well as new migrations without writing any extra  
> migration script.  
> shall I need to use generators, if yes then how?  
> also please let me know what is the best way to achieve this.

If I understand you correctly you are asking how to add/remove fields  
from existing database tables using migrations.

This guide explains pretty much everything you need to know about Rails  
migrations:

> **[Active Record Migrations — Ruby on Rails Guides](https://edgeguides.rubyonrails.org/active_record_migrations.html)**
>
> Active Record MigrationsMigrations are a feature of Active Record that allows you to evolve your database schema over time. Rather than write schema modifications in pure SQL, migrations allow you to use a Ruby DSL to describe changes to your...

This sections specifically explains how to change tables using  
migrations:

> **[Active Record Migrations — Ruby on Rails Guides](https://edgeguides.rubyonrails.org/active_record_migrations.html)**
>
> Active Record MigrationsMigrations are a feature of Active Record that allows you to evolve your database schema over time. Rather than write schema modifications in pure SQL, migrations allow you to use a Ruby DSL to describe changes to your...

Keep in mind that the purpose of migrations is to support an agile  
design methodology to database design. It’s very common to need to add  
new columns, remove columns or rename columns in your database as you  
progress the design of your application.

There is also a special convention for adding/removing columns to a  
table using generators.

Example:  
ruby script/generate migration AddPartNumberToProducts  
part\_number:string

will generate:

class AddPartNumberToProducts \< ActiveRecord::Migration  
def self.up  
add\_column :products, :part\_number, :string  
end

def self.down  
remove\_column :products, :part\_number  
end  
end

Notice that any changes made in self.up gets undone in self.down. One  
key to good migrations is to make sure “down” always reverses the  
changes made in “up.” This allows you to rollback schema changes without  
causing adverse effects.

In some cases (especially with the production environment) this may  
require data migration along with schema migration. For example if you  
find you need to normalize a table you may have to move the data into  
the new schema while making the schema changes. Its up to you to make  
sure reversing that process occurs in the proper order to avoid any data  
loss. If this is required make sure you do sufficient testing before  
running these migrations on production data.