db:setup environment issues


I’ve detected a strange issue with ‘db:setup’ rake task in comparison with other tasks (like ‘db:reset’). This is meant to the core list because I’d love to know if I am pointing to the right direction, and since I haven’t contributed any patches to rails yet, if what I am guessing is correct.

I am only including the relevant part for this issue of each file.

First of all, the environment is a ‘core’ rails project, with mountable engines. Those engines add their own migrations on engine initialization process:

# engine_name/lib/engine_name/engine.rb
module EngineName
  class Engine < ::Rails::Engine
    initializer ‘engine_name.inject_migrations' do |app|
      config.paths['db/migrate'].expanded.each do |path|
        app.config.paths['db/migrate'] << path

Given this setup, all rake tasks that do not include :environment precondition are not going to include this paths on the :load_config call on active record rake tasks:

# active_record/railties/databases.rake
namespace :db do
  task :load_config do
    ActiveRecord::Base.configurations = ActiveRecord::Tasks::DatabaseTasks.database_configuration || {}
    ActiveRecord::Migrator.migrations_paths = ActiveRecord::Tasks::DatabaseTasks.migrations_paths

Which calls ActiveRecord::Tasks::DatabaseTasks.migrations_paths, which leads to:

# active_record/tasks/database_tasks.rb
module ActiveRecord
  module Tasks
    module DatabaseTasks
      def migrations_paths
        @migrations_paths ||= Rails.application.paths['db/migrate'].to_a

And here is where the “problem” resides. When Rails.application.paths is resolved is when migrations_paths is initialized. This means that if no environment is loaded, the engines didn’t have the chance to include their migrations. This is specially important in tasks like ‘db:setup’, because the schema will be properly migrated, but when assuming migrating to the last migration, not every migration will be included in the schema_migrations table, and will lead to `db:migrate` errors afterwards (table already exists and similar problems).

So the question is: would make sense that load_config task depends on environment task? This way we assure that the environment is always loaded.

Thanks in advance.