aboutsummaryrefslogtreecommitdiffstats
path: root/railties/test/application/test_test.rb
diff options
context:
space:
mode:
authoreileencodes <eileencodes@gmail.com>2018-01-10 10:25:13 -0500
committereileencodes <eileencodes@gmail.com>2018-01-18 08:55:03 -0500
commita2827ec9811b5012e8e366011fd44c8eb53fc714 (patch)
treece158384df40f9cfe128bb659b0372a6e7bb8f07 /railties/test/application/test_test.rb
parent198e3e3cb784dae54d8d4346667d3fb08c889335 (diff)
downloadrails-a2827ec9811b5012e8e366011fd44c8eb53fc714.tar.gz
rails-a2827ec9811b5012e8e366011fd44c8eb53fc714.tar.bz2
rails-a2827ec9811b5012e8e366011fd44c8eb53fc714.zip
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.
Diffstat (limited to 'railties/test/application/test_test.rb')
0 files changed, 0 insertions, 0 deletions