# Model validation crashes my early migrations - what to do?

**URL:** <https://www.ruby-forum.com/t/model-validation-crashes-my-early-migrations-what-to-do/91851>\
**Category:** Rails\
**Created:** [April 12, 2007, 9:06pm UTC](https://www.ruby-forum.com/t/model-validation-crashes-my-early-migrations-what-to-do/91851 "2007-04-12T21:06:10Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Andreas\_Hallberg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c37758/32.png) [@Andreas\_Hallberg](https://www.ruby-forum.com/u/Andreas_Hallberg)\
**Post date:** [April 12, 2007, 9:06pm UTC](https://www.ruby-forum.com/t/model-validation-crashes-my-early-migrations-what-to-do/91851/1 "2007-04-12T21:06:10Z")

</div>

Hi all,

I am quite new to RoR but have immediately managed to stumble into some  
migration difficulties.

Some migrations setting up my “users” table:

001\_add\_user.rb

- (creates the users table)  
002\_insert\_test\_user.rb
- (does User.create in the migration to create a test-user in the db)  
003\_add\_username
- (adding new column user\_name. I also add a validation in User.rb:  
validate\_presence\_of :user\_name)

All good and fine until I decide to drop my database and re-create it.  
Then the 002\_insert\_test\_user.rb migration fails because the User class  
tries to validate that user\_name is not blank, but there is no user\_name  
column in the database at this stage.

I solved this problem by out-commenting the code in the  
002\_insert\_test\_user.rb and adding a 004 migration that inserts the test  
user now with a user\_name.

I don’t feel very happy about that workaround, and it seems to me this  
issue will be quite frequent when working in an agile iterative fashion.

Anyone has a best practice of solving this?

Thanks,

Andreas

---

<div class="post-metadata">

**Author:** ![Andreas\_Hallberg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c37758/32.png) [@Andreas\_Hallberg](https://www.ruby-forum.com/u/Andreas_Hallberg)\
**Post date:** [April 12, 2007, 9:16pm UTC](https://www.ruby-forum.com/t/model-validation-crashes-my-early-migrations-what-to-do/91851/2 "2007-04-12T21:16:01Z")

</div>

Personally I usually end up changing the migration itself to put in the  
correct data. It never feels like the right way of doing things, though  
it  
does work.

Another solution is to define the model in your migration:

class MigrationStuff …  
class MyModel \< AR::Base  
end

def self.up  
…  
end  
end

That way you aren’t using the validations, and in the migration were  
validations are added, you can run through the existing data and make  
changes to be sure it won’t break the app further down the line.

Jason

---

<div class="post-metadata">

**Author:** ![Andreas\_Hallberg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c37758/32.png) [@Andreas\_Hallberg](https://www.ruby-forum.com/u/Andreas_Hallberg)\
**Post date:** [April 12, 2007, 9:53pm UTC](https://www.ruby-forum.com/t/model-validation-crashes-my-early-migrations-what-to-do/91851/3 "2007-04-12T21:53:06Z")

</div>

Migrations are for database management, not creation of test data.  
The test framework works quite well to allow you to do setup tasks  
that create test data and then run the test. If you are wanting to  
create test data for manual testing then use a separate controller  
action pair like test/create\_test\_data and point to that in your  
browser. Migrations are at the database level and not the model  
level. The test framework operates above the model and controller  
level so it is a better place to put such logic. I would recommend  
Agile Web D. with Rails as a first book as it is pretty clear  
on the layering and where different types of logic best reside.

If you are wanting to insert static data such as system codes and such  
do that in a final migration, and use SQL statements not model  
methods. That way you are only relying on the database in the  
Migration rather than other layers. The challenge here is that the  
static data is not really part of the database schema and will mess up  
the database versioning that is part of migrations.

Michael

On Apr 12, 12:06 pm, Andreas Hallberg \<rails-mailing-l…@andreas-

---

<div class="post-metadata">

**Author:** ![Andreas\_Hallberg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c37758/32.png) [@Andreas\_Hallberg](https://www.ruby-forum.com/u/Andreas_Hallberg)\
**Post date:** [April 14, 2007, 9:49am UTC](https://www.ruby-forum.com/t/model-validation-crashes-my-early-migrations-what-to-do/91851/4 "2007-04-14T09:49:41Z")

</div>

Hi Michael,

Thanks for your reply; you are right - the data is for manual testing. I  
like your idea with the test data setup controller/action strategy -  
keeps the database clean so I don’t have to clean it up after I have run  
the migrations to create the production database.

BTW I don’t use migrations for unit-test data, I use fixtures - I have  
the book 🙂

Thanks again,

/Andreas