在Rails DB迁移期间截断表是否有风险？

Question

I'm adding a migration that is adding a unique index to a MySQL table. Is there any real risk in truncating any existing data in the table so the unique index can be added, given that existing data in the table may not be unique?

It's important to mention that this app is still in development and has not yet been released to production, and therefore we would not be losing any real user data.

Can anyone come up with a real-world scenario in which we might lose important data down the line?

Code example of the migration:

class AddUniqueIndexToFooOnBarAndBaz < ActiveRecord::Migration
  def up
    ActiveRecord::Base.connection.execute("TRUNCATE foo")
    add_index :foo, [:bar_id, :baz_id], unique: true
  end

  def down
    remove_index :foo, [:bar_id, :baz_id]
  end
end

Answer 1

tl;dr- you won't hurt anything really, but don't do that TRUNCATE anyway. Do a db:reset

What happens when you write a migration is that the db/schema.rb file gets changed and its version is set to the timestamp on the last migration that was run. The migration files exists so that:

1. You can have concrete files which demonstrate the changes to the database over time, using a DSL which makes sense.
2. You can rollback the changes to your database semi-arbitrarily, if you discover something is wrong during development (don't rollback your production DB, just write a new migration)

This means that migration files should show what you're doing to the database and that TRUNCATE isn't really what you're doing to the DB, it's what you're doing to the data . It won't break anything and that SQL snippet won't run if you deploy a new environment using a schema that's already migrated, but for any environment that's already up, it will. That's just kinda weird and definitely unnecessary.

The Details

What happens when you deploy your app for the first time in an environment is you (should) run rake db:create db:schema:load db:seed or rake db:setup (which just farms out to the other commands). db:schema:load simply converts your schema.rb file into an actual database schema, with tables and indices and all that fun stuff. After you've run your migration, your schema file will have the index you want . Then, whenever you deploy to production, your database will look like you want it to out of the box, before any data is added.

In development, you shouldn't be attached to any data that's in your database- it's test data, unimportant and ephemeral. You shouldn't feel bad wiping it all out, especially if you're truncating because the existing data might be invalid/duplicated.

Answer 2

Truncating a table has consequences whether you use a rails migration or not. The better question is to ask whether it's risky to truncate the table, period.

Since you're not in production, there is no risk of impacting "real" people, but what you have to consider is how will truncating the table impact your data integrity and how as a developer, will you recover from any issues you may encounter.

For example, if the data you're truncating is in a join table connecting two other tables, then you've lost the relationship between your two tables and you've basically rendered a significant chunk of your data useless. However, if the data is in an insignificant table, then the impact is a lot lower.

In short, yes, there are risks, but the best person to answer the level of this risk is you.