Rails acts_as_paranoid migration issue

Question

I have a complicated issue with Devise and the paranoia(acts_as_paranoid) gem. My User model is relatively simple:

class User < AR::Base
  devise :confirmable, :other_config_options
  acts_as_paranoid
end

I added the Devise gem first without the confirmable option. Then I later added the confirmable option with this migration:

def up
  add_column :users, :confirmed_at, :datetime
  add_column :users, :confirmation_token, :string
  add_column :users, :confirmation_sent_at, :datetime
  add_column :users, :unconfirmed_email, :string

  add_index :users, :confirmation_token, unique: true

  User.update_all(:confirmed_at => Time.now)
end

No problem up to this point. Then I added the Paranoia gem and the acts_as_paranoid line to the User model. My database is fine in its current state, but I'm trying to reset my database to sync it with production data, and this is where I'm running into problems. When I do a db:reset, it fails the above migration:

PG::UndefinedColumn: ERROR:  column users.deleted_at does not exist

The trouble is that my model contains a directive acts_as_paranoid that is valid only with the current database snapshot. If I roll back to a previous database snapshot, User::deleted_at doesn't exist, the paranoia gem still attempts to update only non-deleted objects, and my query fails.

Any thoughts on an elegant way to handle this situation?

Answer 1

Not entirely sure if this is the most elegant solution, but I solved by updating my old migrations with User.with_deleted.update_all(:confirmed_at => Time.now) (well - my models' version).

May not work if you want users who have deleted_at set to not set confirmed_at; for me, I didn't really care if the deleted users had this field set (for me - this is only an issue in dev/test, and usually happens where there are no records in the first place).

After all this - I think it may be time for me to look at using seeds or a gem for DML migrations