Skip to content
  • eileencodes's avatar
    a2827ec9
    Refactor migration to move migrations paths to connection · a2827ec9
    eileencodes authored
    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.
    a2827ec9
    Refactor migration to move migrations paths to connection
    eileencodes authored
    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.
Loading