Model validation crashes my early migrations - what to do?

Rails
1

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

2

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

3

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-

4

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 :slight_smile:

Thanks again,

/Andreas