Handle edge case where application is unable to run tasks/migrations

[steveyken]

I'm in two minds about this PR so open to alternative views here!

The case I'm addressing is that if DB migrations fail at a particular point (during CustomField creation), then we have a situation where the rails app can't properly initialize because we have code in the custom field initializer that expects certain tables and models to exist.

If the rails app is unable to initialize, we can't re-run migrations to fix the problem and therefore have a catch-22 situation.

Since the code in the custom field initializer only really needs to provide a list to ransack for model names and translations, I think it's ok for it to fail and proceed gracefully. This will enable rake to be run to fix problems and once migrations have run properly, the ransack translation code will run properly at next boot up.

As I mentioned, open to alternative implementations.

[CloCkWeRX]

I've previously done things like looking at Rake.application.top_level_tasks to determine if I'm in a migration/have a DB connection, and skipping initializers that don't work. We sort of have that with Settings.database_and_table_exists? already, though not for the custom fields.

Rather than catching db specific exceptions, is it worth doing a proactive
ActiveRecord::Base.connection.table_exists? :mytable

[CloCkWeRX]

@steveyken I'm not sure either way too on this one. I guess, what's the worst that happens if this is merged?

[steveyken]

Thanks for the ping. I agree that checking for the table existence is clearer to what we actually want. I've updated the code, rebased to master and I'm ready for it to merge into master now.