mysql - Rails 5.0.0.beta1，两个数据库设置创建额外的 active_record_internal_metadatas 表

Question

我正在尝试在 rails 5.0.0.beta1 中实现两个数据库设置。一切似乎都运行良好，但我遇到了一些奇怪的事情。模型连接到指定的数据库、关联工作、迁移(经过一些调整后)也工作正常。在我运行迁移后，一个名为 active_record_internal_metadatas 的附加表出现在两个数据库中。当我在 rails 4.2.5 上测试这个设置时，没有这样的东西。有人可以阐明这个问题吗？

双数据库设置的设置:

• database.yml

  default: &default
  adapter: mysql2
  encoding: utf8
  pool: 5
  username: root
  password:
  socket: /tmp/mysql.sock
  
  development:
    <<: *default
    database: app_name_development_first
  
  development_second:
    <<: *default
    database: app_name_development_second
  

• second_db_connection.rb - 处理与第二个数据库的连接的模型。所有应该在第二个数据库中的模型都必须从这个模型继承。

  class SecondDbConnection < ActiveRecord::Base
      establish_connection "#{Rails.env}_second".to_sym
      self.abstract_class = true
  end
  

• application_controller.rb - 第二个数据库的缓存连接

  class ApplicationController < ActionController::API
    around_filter :cache_other_db_connections
  
    private
      def cache_other_db_connections
        SecondDbConnection.connection.cache { yield }
      end
  end
  

• db.rake - 覆盖迁移任务

  namespace :db do
    task :migrate do
      Rake::Task['db:migrate_first'].invoke
      Rake::Task['db:migrate_second'].invoke
    end
  
    task :migrate_first do
      ActiveRecord::Base.establish_connection ("#{Rails.env}".to_sym)
      ActiveRecord::Migrator.migrate('db/db_first/migrate/')
      ActiveRecord::Base.connection.close
    end
  
    task :migrate_second do
      ActiveRecord::Base.establish_connection ("#{Rails.env}_second".to_sym)
      ActiveRecord::Migrator.migrate('db/db_second/migrate/')
      ActiveRecord::Base.connection.close
    end
  end
  

Answer 1

这似乎是 Rails 5 的一个特性。这是来自 this pull request commit 的引述简介:

Prevent destructive action on production database

This PR introduces a key/value type store to Active Record that can be used for storing internal values. It is an alternative implementation to #21237 cc @sgrif @matthewd.

It is possible to run your tests against your production database by accident right now. While infrequently, but as an anecdotal data point, Heroku receives a non-trivial number of requests for a database restore due to this happening. In these cases the loss can be large.

To prevent against running tests against production we can store the "environment" version that was used when migrating the database in a new internal table. Before executing tests we can see if the database is a listed in protected_environments and abort. There is a manual escape valve to force this check from happening with environment variable DISABLE_DATABASE_ENVIRONMENT_CHECK=1.