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.
On Friday, September 8, 2017 at 6:21:40 PM UTC+1, Christoph Lupprich wrote: > > 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 ;) ). > > On Friday, September 8, 2017 at 1:56:22 PM UTC+2, Ben Edwards wrote: >> >> 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? >>>> >>> -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/e0186bfc-ffa9-4a78-863a-e9f06848f904%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
