Schema Migrations Table

Ruby on-RailsRuby on-Rails-4Database Migration

Ruby 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.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
Questiontommyd456View Question on Stackoverflow
Solution 1 - Ruby on-RailsDavid LowenfelsView Answer on Stackoverflow
Solution 2 - Ruby on-RailsPeter PiperView Answer on Stackoverflow
Solution 3 - Ruby on-RailssteakchaserView Answer on Stackoverflow
Solution 4 - Ruby on-RailslocalhostdotdevView Answer on Stackoverflow
Solution 5 - Ruby on-RailsAgustinView Answer on Stackoverflow
Solution 6 - Ruby on-RailsJeromeView Answer on Stackoverflow