Schema Migrations Table
Ruby on-RailsRuby on-Rails-4Database MigrationRuby on-Rails Problem Overview
In my Rails 4 app I would like to collapse my migration files into one large file (similar to schema.rb) as it's time to do some housekeeping but I'm not sure on how to access the table in the database that stores migration data so that when I run a migration I don't receive any errors/conflicts.
Question How can I access and delete the data in the table that stores migration data?
Ruby on-Rails Solutions
Solution 1 - Ruby on-Rails
for fun, you can also manipulate these in the console by making a model class for them...
class SchemaMigration < ActiveRecord::Base; self.primary_key = :version; end
then you can do SchemaMigration.all, SchemaMigration.last.delete, etc.
Really just a substitute for using SQL, and it is very rare that you would need to mess around at this low level… generally a bad idea but cool to see how to do it :)
Solution 2 - Ruby on-Rails
Another solution could be to access it through:
ActiveRecord::SchemaMigration
The answer given by David didn't work in my context.
Solution 3 - Ruby on-Rails
The schema_migrations
table holds the revision numbers; with the last record being the most recently executed migration. You can just manipulate these records manually.
Solution 4 - Ruby on-Rails
to get the last version:
ActiveRecord::SchemaMigration.last.version
or all versions:
ActiveRecord::SchemaMigration.all.map(&:version)
Solution 5 - Ruby on-Rails
Not sure why you want to do this but here you go:
ActiveRecord::Migrator.get_all_versions
Solution 6 - Ruby on-Rails
I've had to do some cleanup of the sort: accumulation of seemingly trivial migrations create such pollution that things stop making sense.
As a last phase of development (not recommended once in production), you can clear out the schema_migrations table, consolidate your migrations (one-to-one with classes) and create a new table (beware: running migrate
has different behaviours, depending on mysql vs postgresql)
@david-lowenfels answer is perfect for this context.
All this, naturally, assumes you haven't made errors in keys, indices, defaults. This is a serious task, but not an insensible one at the end of a development phase.