• E
    Restore previous behavior of parallel test databases · c0509885
    eileencodes 提交于
    This commit is somewhat of a bandaid fix for a bug that was revealed in #38029
    and then #38151. #38151 can cause problems in certain cases when an app has
    a 3-tier config, with replicas, because it reorders the configuration
    and changes the implict default connection that gets picked up.
    
    If an app calls `establish_connection` with no arguments or doesn't call
    `connects_to` in `ApplicationRecord` AND uses parallel testing
    databases, the application may pick up the wrong configuration.
    
    This is because when the code in #38151 loops through the configurations
    it will update the non-replica configurations and then put them at the
    end of the list. If you don't specify which connection you want, Rails
    will pick up the _first_ connection for that environment. So given the
    following configuration:
    
    ```
    test:
      primary:
        database: my_db
      replica:
        database: my_db
        replica: true
    ```
    
    The database configurations will get reordered to be `replica`,
    `primary` and when Rails calls `establish_connection` with no arguments
    it will pick up `replica` because it's first in the list.
    
    Looking at this bug it shows that calling `establish_connection` with no
    arguments (which will pick up the default env + first configuration in
    the list) OR when `establish_connection` is called with an environment
    like `:test` it will also pick up that env's first configuration. This
    can have surprising behavior in a couple cases:
    
    1) In the parallel testing changes we saw users getting the wrong db
    configuration and hitting an `ActiveRecord::ReadOnlyError`
    2) Writing a configuration that puts `replica` before `primary`, also
    resulting in a `ActiveRecord::ReadOnlyError`
    
    The real fix for this issue is to deprecate calling
    `establish_connection` with an env or nothing and require an explcit
    configuration (like `primary`). This would also involve blessing
    `:primary` as the default connection Rails looks for on boot. In
    addition, this would require us deprecating connection specification
    name "primary" in favor of the class name always since that will get
    mega-confusing (seriously, it's already mega-confusing).
    
    We'll work on fixing these underlying issues, but wanted to get a fix
    out that restores previous behavior.
    Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>
    c0509885
test_databases.rb 788 字节