This project is archived and is in readonly mode.

Migration up and down inconsistent

#1132

Assume the following sequence of actions:

script/generate model contractor first:string last:string rake db:migrate script/generate model company name:string rake db:migrate script/generate model company_contractor company_id:integer contractor_id:integer edit company_contractor.rb, company.rb, and contractor.rb models appropriately to add proper relationships as follows:

company.rb

add has_many :company_contractor, :dependent => :destroy
add has_many :contractors, :through => :company_contractor

contractor.rb

add has_many :company_contractor, :dependent => :destroy

add has_many :companies, :through => :company_contractor

company_contractor.rb

add belongs_to :company, :foreign_key => :company_id
add belongs_to :contractor, :foreign_key => :contractor_id

rake db:migrate

Now at some point during development and testing you decide to migrate back to only having company.

After you've done your work, you try to migrate one step at a time back to the full database.

Raking one migration at a time fails with an error message similar to:

== 20080920075233 CreateCompanies: never migrated, skipping =================

But if you migrate to the complete database everything succeeds and you can then revert back to the point before company_contractor was created.

In other words, you need to migrate the entire database set, then revert your migrations to the point you need instead of being able to just run the one migration.

Reported by feldercarb · September 29th, 2008 @ 08:53 AM

Activity

Pratik
- State changed from new to invalid
This is expected behavior. You shouldn't migrate back, but generate a new migration dropping contractor table.

Thanks.

January 5th, 2009 @ 05:06 PM
feldercarb
Unfortunately, by your logic, in order to debug a database construction issue you would have to create a migration that resets your database to the test state and add another migration to get back to the point you need to be. So instead of debugging your problem, you're adding to the issue before you fix the problem.

Look beyond the example that identified the problem and examine the problem instead.

The problem is that if you run one migration at a time and try to revert a migration, the system generates an exception. But if you migrate the entire database at a single time, reverting migrations works properly.

Another example of this would be when you attempt to move your system to a new machine and need to run the migrations but encounter an exception (assume a name you used is now a reserved word or is already in use). Now for proper QA in some organizations (like mine) you need to run each step to isolate the bug and duplicate the bug in front of multiple people. When you do this, the migrations throw exceptions instead of the database throwing the exception which is what you're trying to demonstrate.

January 7th, 2009 @ 08:08 AM