Ruby on Rails

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

On Thursday, September 7, 2017 at 8:24:55 PM UTC+1, Christoph Lupprich wrote:

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

On Thursday, September 7, 2017 at 7:49:23 PM UTC+2, Ben Edwards wrote:

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?