0

I wanted to get rid of some development experimentation so I started destroying my models and controllers and then I went to the db part of the job. Looking at previous answers like this Rails DB Migration - How To Drop a Table? and the API guide for Rails 5 I ve realized that dropping a specific table is not as straightforward as "rails destroy controller users"... But why is that?

A previous stackoverflow post suggested running bundle exec... before going after the controller and models but I ve lost that ship now.

In short: can someone describe with some technical insight the steps that I should go after to remove the remnant table in detail now AND explain to me why is not as simple to delete a specific table at this point?

A best practice guide for rolling back experimentations would be appreciated.

Community
  • 1
  • 1
alexandros84
  • 321
  • 4
  • 14
  • If you used `rails g model Foo` then a `_create_foos` table migration was also created where you can reverse that migration with `rake db:migrate:down VERSION=`. – Vucko Nov 22 '16 at 10:16

2 Answers2

3

@deepak handled the "detailed" part. I'll answer the "why"

AND explain to me why is not as simple to delete a specific table at this point?

Simple answer: teamwork, automation and documentation. All your database changes must go through migrations. It is this way so that when your colleagues receive your changes, they don't have to hunt you down and interrogate for what specific tables with what structure need to be created now. They just need to run rake db:migrate and that's it.

If you didn't commit your changes yet (the table exists only for you locally), then it is safe to rollback the migration and delete migration file. Otherwise, if the table exists in other environments, you have to publish a reverse migration.

Sergio Tulentsev
  • 226,338
  • 43
  • 373
  • 367
  • So basically what you are saying is that the present structure is not a matter of necessity but of choice.. interesting. So the migration helps everybody keep in the same page? And how do you check on this record? through logs I suspect.. – alexandros84 Nov 22 '16 at 18:13
  • @alexandros84: How do you check on what? Rails will refuse to start if your db is not up-to-date. It'll prompt you to run migrations. – Sergio Tulentsev Nov 22 '16 at 18:14
  • You mentioned teamwork. I am alone now but i guess that most real life apps have a lot of ppl working behind them. Migrations are like a milestone that keeps everybody in the same page? – alexandros84 Nov 22 '16 at 18:18
  • Yep, something like that. – Sergio Tulentsev Nov 22 '16 at 18:19
1

You can just follow the step in reverse order that you used to create the model

E.g 

rails g model User name:string email:string:index

then you run migrations

rake db:migrate

Now, If you need to destroy the Model

First, rollback the migration

rake db:rollback

and then destroy it using

rails d model User name:string email:string:index
Deepak Mahakale
  • 22,834
  • 10
  • 68
  • 88