Understanding scema_migrations schema.rb

[Ben Edwards]

Hi, ime trying to get my head around how these interact as I acidentely deleted a migration and had not commited it to git.

The migration is 'up'. So I did some research and it seems if I just delete the migration from the schema_migrations (and make sure the corresponding database object does not exist) will fix it. So I had a look at scema_migrations table and this got me wondering how rails knows if the migration is up or down, there is not status attribute on the table.

So I did some more research and came across db/schema.rb, which rails used to work out if a migration is up or down. I looked in log/development.log to doble check what the migration was doing and found 'CREATE TABLE "create_report_upcoming_events" so I checked db/schema.rb and sure enough there is a reference to the view. This is not domething I want and it has not been put into production.  So it seems if I just delete the record from the scema_migrations table things will still be inconsistent.

So do I delete the row from schema_migrations and the reference to the view in db/schema.rb or will just deleting the migration from scema_migrations sufice?

[Christoph Lupprich]

Hi Ben!

I can highly suggest the corresponding Rails Guide on this topic: http://edgeguides.rubyonrails.org/active_record_migrations.html

schema.rb contains the current structure of your database. When you migrate up or down, schema.rb is updated and will always reflect the latest state. You can also manually re-generate it by invoking the db:schema:dump rake task.

The individual migration files describe a change to your database (removing/adding columns, adding/removing tables,...). Each migration has a version number (which is a timestamp), and as soon as that migration is run (up), Rails writes a new row into the schema_migrations with the timestamp of the migration. When you down-migrate a migration, Rails deletes that row from the schema_migrations table.

Coming to your final question on how to best restore the state of your database, without the missing migration: If you don't have any important data in your database (i.e. it's just develop or test), I'd do a git reset --hard (which will give you a clean HEAD), and then invoke the db:structure:load rake task (which will delete the current structure of your DB and replace it with what's defined in your schema.rb).

[Ben Edwards]

Thanks, I do have scripts that backup the database, there is configuration data in there.  git reset --hard / db:structure:load seems a bit drastic.  It seems if I run db:schema:dump (and the view created by the lost migration is not in the DB) that would get things back in sync and effectively put the lost migration 'down' (or remove it altogether as I gather if a migration is down and you have not put it in production it is safe to delete the file).

[Ben Edwards]

PS thanks for the link to the guide.  Have been looking through it.

[Christoph Lupprich]

Right, I missed the part where you said you didn't run the migration. In that case, it's fine to just delete the migration file (which you did ;) ).

[Ben Edwards]

No, I did run the migration, but just on development.  Guess I need to go the db:structure:load route (and make sure the deleted migration is not is schema.rb).  If I all my branches are in sync do I need to do a 'git reset --hard'.  If so I will read up what it does, makes my nervous running stuff i don’t fully understand that seems drastic.