This project is archived and is in readonly mode.
Migration up and down inconsistent
Reported by feldercarb | September 29th, 2008 @ 08:53 AM | in 2.x
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.
Comments and changes to this ticket
-
Pratik January 5th, 2009 @ 05:06 PM
- State changed from “new” to “invalid”
This is expected behavior. You shouldn't migrate back, but generate a new migration dropping contractor table.
Thanks.
-
feldercarb January 7th, 2009 @ 08:08 AM
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.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>
feldercarb