# Intial data in Migrations

**URL:** <https://www.ruby-forum.com/t/intial-data-in-migrations/53600>\
**Category:** Rails\
**Created:** [February 11, 2006, 1:02am UTC](https://www.ruby-forum.com/t/intial-data-in-migrations/53600 "2006-02-11T01:02:50Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![seanwarburton](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/2bfe46/32.png) [@seanwarburton](https://www.ruby-forum.com/u/seanwarburton)\
**Post date:** [February 11, 2006, 1:02am UTC](https://www.ruby-forum.com/t/intial-data-in-migrations/53600/1 "2006-02-11T01:02:50Z")

</div>

One thing I found annoying about Migrations, besides that you have a  
very limited ways to define your data, is that it will overwrite  
EVERYTHING in your schema file. So if you spend hours customizing your  
initial schema file, to get it work, exactly like you’ll need it, that  
work immediately becomes for nothing once you run a migration. Your  
entire schema will get rewritten, not appended to.

In that case, with migrations, how is one suppose to handle initial  
data, such a look up table (such as state or country). Do those get  
put into a separate file? something like an initialize\_db.rb?

How have others been able to handle this with migrations?

–  
Sean W.  
master nerd of  
i heart squares, Co.

3711 N. Ravenswood Ave. #147 Chicago, IL 60613  
Ph. (773) 531-6301 Fx. (773) 529-7041  
[http://www.iheartsquares.com](http://www.iheartsquares.com)

---

<div class="post-metadata">

**Author:** ![seanwarburton](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/2bfe46/32.png) [@seanwarburton](https://www.ruby-forum.com/u/seanwarburton)\
**Post date:** [February 11, 2006, 2:04am UTC](https://www.ruby-forum.com/t/intial-data-in-migrations/53600/2 "2006-02-11T02:04:03Z")

</div>

db/migrate:  
001\_create\_schema.rb  
002\_load\_units.rb  
003\_load\_settlement\_states.rb

–  
– Tom M.

---

<div class="post-metadata">

**Author:** ![seanwarburton](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/2bfe46/32.png) [@seanwarburton](https://www.ruby-forum.com/u/seanwarburton)\
**Post date:** [February 13, 2006, 3:14pm UTC](https://www.ruby-forum.com/t/intial-data-in-migrations/53600/3 "2006-02-13T15:14:18Z")

</div>

On 11 Feb 2006, at 1:03 am, Tom M. wrote:

> > entire schema will get rewritten, not appended to.  
> > 003\_load\_settlement\_states.rb  
> > Or, in other words, don’t edit schema.rb directly. Everything that  
> > you were putting in schema.rb by hand, put into your first migration  
> > instead. It should be your first migration that sets up the database  
> > from scratch.

As it says at the top of schema.rb:

# This file is autogenerated. Instead of editing this file, please

use the

# migrations feature of ActiveRecord to incrementally modify your

database, and

# then regenerate this schema definition.

Chris

---

<div class="post-metadata">

**Author:** ![seanwarburton](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/2bfe46/32.png) [@seanwarburton](https://www.ruby-forum.com/u/seanwarburton)\
**Post date:** [February 13, 2006, 5:54pm UTC](https://www.ruby-forum.com/t/intial-data-in-migrations/53600/4 "2006-02-13T17:54:26Z")

</div>

Chris M. \<chris@…\> writes:

> > > How have others been able to handle this with migrations?  
> > > See below for a plugin I’ve been working on.

> Or, in other words, don’t edit schema.rb directly.  
> Agreed.

It isn’t fully baked yet, but I have a plugin that does this. It’s  
called the  
“first\_migration” plugin.

Here’s how you install it:

script/plugin source [http://damonclinkscales.com/svn/plugins/](http://damonclinkscales.com/svn/plugins/)  
script/plugin install first\_migration

Here’s how you run it:  
script/generate first\_migration

USAGE: generate first\_migration (equal to generate first\_migration  
InitialSchema ruby)  
generate first\_migration ClassName sql (runs  
db\_structure\_dump)  
generate first\_migration ClassName sql [file1.sql] (just uses  
db/file1.sql instead)  
generate first\_migration ClassName ruby (runs db\_schema\_dump)  
generate first\_migration ClassName ruby [file1.rb] (just uses  
db/file1.rb instead)

What it does:

It builds a migration file from one of four sources:

1. your db as a Rails structure dump
2. your db as a Rails schema dump
3. your db as a sql file (custom)
4. your db as a ruby schema file (custom)

Please send me feedback, as I am still improving it to handle all  
scenarios.

Back up your existing data because it doesn’t quite handle all  
situations with  
existing data quite yet.

Best,

-damon

> **[Damon Clinkscales](https://damonc.onuniverse.com/)**
>
> Damon Clinkscales