1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
rails--rails/activerecord/lib/active_record/schema.rb

62 lines
2 KiB
Ruby
Raw Normal View History

# frozen_string_literal: true
module ActiveRecord
# = Active Record \Schema
2010-08-05 11:15:07 -04:00
#
# 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|
2012-09-07 14:27:08 -04:00
# t.string :name, null: false
# end
#
# add_index :authors, :name, :unique
#
# create_table :posts do |t|
2012-09-07 14:27:08 -04:00
# t.integer :author_id, null: false
# t.string :subject
# t.text :body
2012-09-07 14:27:08 -04:00
# 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.
2015-12-05 16:39:30 -05:00
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?
connection.schema_migration.create_table
connection.assume_migrated_upto_version(info[:version])
end
ActiveRecord::InternalMetadata.create_table
Refactor migration to move migrations paths to connection 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.
2018-01-10 10:25:13 -05:00
ActiveRecord::InternalMetadata[:environment] = connection.migration_context.current_environment
end
end
end