mirror of
https://github.com/rails/rails.git
synced 2022-11-09 12:12:34 -05:00
a2827ec981
Rails has some support for multiple databases but it can be hard to
handle migrations with those. The easiest way to implement multiple
databases is to contain migrations into their own folder ("db/migrate"
for the primary db and "db/seconddb_migrate" for the second db). Without
this you would need to write code that allowed you to switch connections
in migrations. I can tell you from experience that is not a fun way to
implement multiple databases.
This refactoring is a pre-requisite for implementing other features
related to parallel testing and improved handling for multiple
databases.
The refactoring here moves the class methods from the `Migrator` class
into it's own new class `MigrationContext`. The goal was to move the
`migrations_paths` method off of the `Migrator` class and onto the
connection. This allows users to do the following in their
`database.yml`:
```
development:
adapter: mysql2
username: root
password:
development_seconddb:
adapter: mysql2
username: root
password:
migrations_paths: "db/second_db_migrate"
```
Migrations for the `seconddb` can now be store in the
`db/second_db_migrate` directory. Migrations for the primary database
are stored in `db/migrate`".
The refactoring here drastically reduces the internal API for migrations
since we don't need to pass `migrations_paths` around to every single
method. Additionally this change does not require any Rails applications
to make changes unless they want to use the new public API. All of the
class methods from the `Migrator` class were `nodoc`'d except for the
`migrations_paths` and `migrations_path` getter/setters respectively.
70 lines
2.2 KiB
Ruby
70 lines
2.2 KiB
Ruby
# frozen_string_literal: true
|
|
|
|
module ActiveRecord
|
|
# = Active Record \Schema
|
|
#
|
|
# Allows programmers to programmatically define a schema in a portable
|
|
# DSL. This means you can define tables, indexes, etc. without using SQL
|
|
# directly, so your applications can more easily support multiple
|
|
# databases.
|
|
#
|
|
# Usage:
|
|
#
|
|
# ActiveRecord::Schema.define do
|
|
# create_table :authors do |t|
|
|
# t.string :name, null: false
|
|
# end
|
|
#
|
|
# add_index :authors, :name, :unique
|
|
#
|
|
# create_table :posts do |t|
|
|
# t.integer :author_id, null: false
|
|
# t.string :subject
|
|
# t.text :body
|
|
# t.boolean :private, default: false
|
|
# end
|
|
#
|
|
# add_index :posts, :author_id
|
|
# end
|
|
#
|
|
# ActiveRecord::Schema is only supported by database adapters that also
|
|
# support migrations, the two features being very similar.
|
|
class Schema < Migration::Current
|
|
# Eval the given block. All methods available to the current connection
|
|
# adapter are available within the block, so you can easily use the
|
|
# database definition DSL to build up your schema (
|
|
# {create_table}[rdoc-ref:ConnectionAdapters::SchemaStatements#create_table],
|
|
# {add_index}[rdoc-ref:ConnectionAdapters::SchemaStatements#add_index], etc.).
|
|
#
|
|
# The +info+ hash is optional, and if given is used to define metadata
|
|
# about the current schema (currently, only the schema's version):
|
|
#
|
|
# ActiveRecord::Schema.define(version: 2038_01_19_000001) do
|
|
# ...
|
|
# end
|
|
def self.define(info = {}, &block)
|
|
new.define(info, &block)
|
|
end
|
|
|
|
def define(info, &block) # :nodoc:
|
|
instance_eval(&block)
|
|
|
|
if info[:version].present?
|
|
ActiveRecord::SchemaMigration.create_table
|
|
connection.assume_migrated_upto_version(info[:version], migrations_paths)
|
|
end
|
|
|
|
ActiveRecord::InternalMetadata.create_table
|
|
ActiveRecord::InternalMetadata[:environment] = connection.migration_context.current_environment
|
|
end
|
|
|
|
private
|
|
# Returns the migrations paths.
|
|
#
|
|
# ActiveRecord::Schema.new.migrations_paths
|
|
# # => ["db/migrate"] # Rails migration path by default.
|
|
def migrations_paths
|
|
ActiveRecord::Migrator.migrations_paths
|
|
end
|
|
end
|
|
end
|