What is the best way to drop a table & remove a model in Rails 3?

Question

I have a model & a table which I no longer need in my App, I could leave them there but I would like to remove them to keep things tidy.

I'm trying to figure out the best way to remove them with out messing around with my migrations & db/schema.rb files & any side effect it could have on my production environment, my app is on Heroku. I'm using PostgreSQL on both my local machine & heroku.

So far I've found two ways to do this but am not sure which is the best method/ rails way?

Method 1

I thought about just going in to my database & dropping the table & then destroying the model.

rails db
DROP TABLE table_name
\q
rails destroy model model_name

If I do this what will happen to the migrations I have for this model/table? I have two migrations for this model, a timestamp_create_modelname & a add_attribute_to_table name.

Also will this method update the db/schema.rb file?

When I push the App to Heroku I suspect the Model will be removed but the table will remain in place, is there a heroku command to drop a table.

Method Two

Another way I read about was to generate a new migration to drop the table & then destroy the model.

rails generate migration drop_tablename

& then update the below file:

db/migrate/timestamp_drop_tablename (updated in response to Dan Wich's answer below)

class DropTablename < ActiveRecord::Migration
  def up
    drop_table :tablename
  end

  def down
    create_table :tablename do |t|
      t.string :table_column
      t.references :anothertable

      t.timestamps        
    end
    add_index :tablenames, :anothertable_id
  end
end

& then in the terminal:

rake db:migrate
rails destroy model model_name
rake db:migrate
git add .
git commit -m "removed table/model_name"
git push heroku master
heroku run rake db:migrate
heroku restart

This seems to be the best method but what happens to the older migration files? Will they remain & update db/schema every time I run rake db:migrate only to be overridden by db/migrate/timestamp_drop_tablename?

I'm happy to experiment with the second method but would like someone with someone with experience to weigh in & tell me the rails ways for doing this.

Answer 1

The second method is the ideal way to handle this: your migration files are meant to represent how your database has changed over time. The older migration files will remain in your project (in case, hypothetically, you wanted to roll back to an older version), but Rails will not run them when you rake db:migrate because it knows they've already been run (based on data in the database's schema_migrations table).

Your schema.rb will just be updated once to reflect that your database no longer contains that table.

One minor tweak to your code: your migration file should drop the table in the up method, and ideally recreate it in the down method. The "up" signifies that your migration drops the table to move forward in time, and if the migration is rolled back, the down method will be run.