Question

Here’s a bit of an odd question that’s partially covered in some other posts, but not adequately answered directly. We have some migration version numbers in our schema_migrations database that were dumped in there at some point years ago by a ham-fisted plugin:

Ever since that fated day, our schema has looked like this:

ActiveRecord::Schema.define(:version => 20090409010513002) do


Since the migration version numbers are longs, Rails will ever assume that we are at a schema version created roughly 60 million years in the future.

Now, one would think, this is safe, given that the migration documentation says that the up method is called on all migrations that are not run on a given database will be run. This seems to be the case, since we have been creating migrations for the past 3 years and running them successfully. It appears that Rails is saying “You’re officially migrated to version 20090409010513002, but haven’t yet run migration (something in 2012), so I’ll run that and add it to the database.

My question is two-fold:

1. Is there any hidden danger to the status quo? Things seem to be working well enough, but I want to know they will continue to do so.
2. Since those extra-long migration numbers don’t actually have migration files attached to them (there is a file for 20090409010513, but neither for the 001 or 002 versions), is there any harm at all in deleting these rows, thereby having Rails realize the true latest migration?

Answer 1

For the first question, one danger I can think of is that your db/schema.rb file won’t be as useful to figure out whether it corresponds to what’s in the database.

For the second question – I’m assuming the screen shot is from your production database. What do you see in the schema_migrations table if you do rake db:setup in a development environment? If the schema_migrations table in development doesn’t have those two bogus entries, I think it’s probably safe to delete them from the production database.