config/vanity.yml not used by db:create and db:migrate

[chrisandrewcl]

This is a follow up from https://github.com/assaf/vanity/issues/277:

After @phillbaker suggestion vanity seems to be querying the correct database (defined in vanity.yml), resulting in FATAL: database "hotsite_vanity_dev" does not exist, because db:create and db:migrate still take effect on database defined in database.yml.

Also, if I force vanity.yml to be used on create/migrate, activesupport will complain because it doesn't know what to do with "active_record" adapter

Any suggestions?

[chrisandrewcl]

This is how I tried put this to work:

#/home/chrisandrew/workspace/gomes-hotsite/lib/tasks/vanity_db_fix.rake
desc "Migrate the database through scripts in db/migrate."
namespace :db do
  APP_PATH = File.expand_path('../../../', __FILE__)
  db_conf = YAML::load(File.open(File.join(APP_PATH,'config','vanity.yml')))
  DB_VANITY = db_conf[ENV['RAILS_ENV']]

  task :create_vanity do
    ActiveRecord::Base.establish_connection DB_VANITY.clone.merge('database' => nil)
    ActiveRecord::Base.connection.create_database DB_VANITY['database']
  end

  task :drop_vanity do
    ActiveRecord::Base.establish_connection DB_VANITY.clone.merge('database' => nil)
    ActiveRecord::Base.connection.drop_database DB_VANITY['database']
  end

  task :migrate_vanity do
    ActiveRecord::Base.establish_connection DB_VANITY
    ActiveRecord::Migrator.migrate("db/migrate_vanity/")
  end

  Rake::Task["db:create"].enhance do
    Rake::Task["db:create_vanity"].invoke
  end

  Rake::Task["db:drop"].enhance do
    Rake::Task["db:drop_vanity"].invoke
  end

  Rake::Task["db:migrate"].enhance do
    Rake::Task["db:migrate_vanity"].invoke
  end

end

#/home/chrisandrew/workspace/gomes-hotsite/config/initializers/vanity_db_fix.rb

require 'rails/generators'
require 'rails/generators/migration'

module VanityGeneratorFix
  def create_model_file
    migration_template "vanity_migration.rb", "db/migrate_vanity/vanity_migration.rb"
  end
end

class VanityGenerator < Rails::Generators::Base
  prepend VanityGeneratorFix
end

[phillbaker]

Thanks for opening the issue @ChrisAndrew and thanks for the workaround, I'll take a look and see if we can get a fix into master.

[phillbaker]

@ChrisAndrew I've merged a fix and will bump the gem version in a couple of days. You'll need the new code and to regenerate the migration file to get the fix.

[jalada]

I might be wrong but I think this change reintroduces some issues related to https://github.com/assaf/vanity/issues/81 and https://github.com/assaf/vanity/issues/77.

I cannot run rake db:migrate in production on Heroku because before the migrations run Vanity attempts to load all my experiments, which tries to access my DB (I'm using the ActiveRecord adapter), which doesn't work because I need the migration to run first.

This is because schema_relevant? returns true (because I'm running a DB task), causing Vanity.load! to run in the Rails initialiser during my rake task, causing the entire playground to load.

[phillbaker]

@jalada thanks for pointing it out, I've re-opened this issue.

[chrisandrewcl]

@phillbaker I've just checked Vanity 2.2.1 and the behaviour is the same: db:migrate and bd:create still take effect on database defined in database.yml and FATAL: database "hotsite_vanity_dev" does not exist is throw at runtime.

Let me know If there is any more info I can provide to help with it.

[chrisandrewcl]

@phillbaker Forget it! Sorry! I've realized that I needed to re-generate vanity migrations in order to it to work.

Considerations: db:migration runs fine, but vanity DB must be created (or dropped) by hand, since db:create/drop isn't considering vanity; vanity still depends on database.yml since schema_migrations resides on the application DB (which seems fine by now).

[phillbaker]

@ChrisAndrew @jalada I've reverted the check that uses schema_relevant?, and pushed a new version of vanity, so we should be back at the same place as the beginning of this bug, where db:create and db:migrate fail to use a database defined in vanity.yml. I took some more time to dig through how this should work, but it'll take a bit more work.