Migration issue due to `ActiveAdmin` removal

[orenyk]

Since we've removed ActiveAdmin in v4.0, one of our earlier migrations (20140611142209_move_admin_notes_to_comments.rb) is failing with a NameError on newly created databases. Existing databases that have already undergone that migration will be fine. I'm not sure what the proper solution to this is, but it's kinda important. Interestingly, I'm not sure why our Travis builds haven't been failing since I thought it created the database from scratch each time. Either way, we need to resolve this.

• fix migrations
• fix test:prepare issue

[orenyk]

Ok, so I can avoid the migration error by running rake db:schema:load instead, but my tests are now raising a MySQL error:

/home/oren/.rvm/gems/ruby-2.1.2@STC-reservations/gems/activerecord-4.1.4/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:303:in `query': Mysql2::Error: Table 'reservations_test.app_configs' doesn't exist: SELECT  `app_configs`.* FROM `app_configs`   ORDER BY `app_configs`.`id` ASC LIMIT 1 (ActiveRecord::StatementInvalid)

What's weird is that I've been running rake test:pepare beforehand and it doesn't raise any errors... my investigation continues!

[orenyk]

Ok, so apparently there's a difference between running rake db:test:prepare and just running rake test:prepare. I've been using the latter and Travis uses the former; when I use the former the test suite runs fine. That said, when I run rake db:test:prepare I get the following deprecation warning:

WARNING: db:test:prepare is deprecated. The Rails test helper now maintains your test schema automatically, see the release notes for details.

I'll keep digging...

[orenyk]

Ok, I think I've figured it out, looks like some stuff in RSpec has changed and we're a bit behind the times. I found that we need to add a line to our helper file to automatically prepare the test database when we call rspec (see here), and that this has been updated in the most recent default spec_helper.rb (which is now called rails_helper.rb) (see here). I'm not sure what happens when you update rspec but don't change the file name, but I'm assuming they've worked that out :-P. Anyway, I've tweaked our spec_helper.rb and now running rspec after rake db:create and rake db:schema:load works fine. I'll open up a PR w/ the fix!

[orenyk]

Ok, so that didn't really resolve the issue, but it's at least useful. I'll get back to the migration issue tomorrow.

[squidgetx]

It seems that the migrations can't run without whatever constants AA provides..It's irritating since in versions 4+ all the AA code/migrations are completely irrelevant anyway, but we can't just delete those migrations.. (or can we?)

[orenyk]

I don't know, that's what I'm not sure about. For new installations, the only place where this crops up, we don't care about adding the AA stuff before removing it. That said, we need the new removal migration for our existing deployments, but it will error out if we don't do the old one. We could potentially edit the problematic migration to take out references to the AA constant (as long as it left the db in the same state, I don't think we care). Does that make sense?

[squidgetx]

I don't know if that will be doable, it sounds a little sketchy.

IIRC, db:schema:load is the standard for setting up new production instances, not rake db:migrate solely because of complications like this one. I think it might be fine to allow this migration conflict to simply go by the by; no one should be running migrations from scratch which is the only way this error could be triggered. Both sets of migrations (setting up AA, and removing it) need to exist in their current forms for people upgrading to 3.4 and to 4.0 respectively.