1. 14 9月, 2020 1 次提交
  2. 10 9月, 2020 1 次提交
  3. 02 9月, 2020 2 次提交
  4. 01 9月, 2020 1 次提交
  5. 18 12月, 2019 1 次提交
    • J
      Deprecate `connection_config` · 5a374351
      John Crepezzi 提交于
      The `connection_config` method returns a `Hash`, but since we're moving
      toward a place where we're using `DatabaseConfiguration::DatabaseConfig`
      objects everywhere, we're introducing a new method here to replace it
      called `connection_db_config`.
      Co-authored-by: Neileencodes <eileencodes@gmail.com>
      5a374351
  6. 07 11月, 2019 1 次提交
    • E
      Rename the classes · 6d81eab1
      eileencodes 提交于
      This commit renames `RoleManager` -> `PoolManager` and `Role` ->
      `PoolConfig`.
      
      Once we introduced the previous commit, and looking at the existing
      code, it's clearer that `Role` and `RoleManager` are not the right names
      for these.
      
      Since this PR moves away from swapping the connection handler concepts
      around and the role concept will continue existing on the handler level,
      we need to rename this.
      
      A `PoolConfig` holds a `connection_specification_name` (we may rename
      this down the road), a `db_config`, a `schema_cache`, and a `pool`. It
      does feel like `pool` could eventually hold all of these things instead
      of having a `PoolConfig` object. This would remove one level of the
      object graph and reduce complexity. For now I'm leaving this object to
      keep the change churn low and will revisit later.
      Co-authored-by: NJohn Crepezzi <seejohnrun@github.com>
      6d81eab1
  7. 18 10月, 2019 1 次提交
    • E
      Merge ConnectionSpecification + Role -> Role · eeacc034
      eileencodes 提交于
      In order to move schema_cache off of DatabaseConfiguration we needed to
      make role accessible on pool.
      
      While looking at `ConnectionSpecification`, `Role`, and `DatabaseConfig` John
      and I noticed that this could be achieved by merging `ConnectionSpecification`
      and `Role` into one `Role` class. This allows us to eliminate the `spec`
      concept which is confusing. `spec` is a private method so renaming
      to `resolve_role` is ok.
      
      In the `Role` class we took `name` (renamed to `connection_specification_name`
      for clarity since it's not a `role` name) and `db_config` from
      `ConnectionSpecification` and the `pool` methods from `Role` and combined
      them into one `Role` class.
      
      This feels a lot cleaner to us because it clarifies the purposes of the
      classes/methods/variables, and makes it easier to drop
      `connection_specification_name` keyed on the parent class in the future.
      
      There are a lot of changes in here but the majority of them are find and
      replace `spec` -> `role`, `spec.name` ->
      `role.connection_specification_name`, `Resolver#spec` ->
      `Resolver#resolve_role`.
      
      This PR also moves the `schema_cache` from `DatabaseConfig` to the new
      combined `Role` class.
      Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>
      eeacc034
  8. 20 7月, 2017 1 次提交
  9. 02 7月, 2017 1 次提交
  10. 01 7月, 2017 1 次提交
  11. 24 4月, 2015 1 次提交
    • P
      Silence warning from MySQL::Error object in test · 150f4099
      Prem Sichanugrist 提交于
      When running Active Record MySQL test, this warning is printed in the
      console:
      
          warning: instance variable errno not initialized
      
      It turns out that this is a warning from `mysql` gem in MySQL::Error
      object. However, since the `mysql` gem is no longer maintained, and
      there won't be a newer version, it make sense for us to just silence
      this warning to make the output cleaner.
      150f4099
  12. 17 3月, 2015 1 次提交
    • B
      Closes rails/rails#18864: Renaming transactional fixtures to transactional tests · 09658635
      Brandon Weiss 提交于
      I’m renaming all instances of `use_transcational_fixtures` to
      `use_transactional_tests` and “transactional fixtures” to
      “transactional tests”.
      
      I’m deprecating `use_transactional_fixtures=`. So anyone who is
      explicitly setting this will get a warning telling them to use
      `use_transactional_tests=` instead.
      
      I’m maintaining backwards compatibility—both forms will work.
      `use_transactional_tests` will check to see if
      `use_transactional_fixtures` is set and use that, otherwise it will use
      itself. But because `use_transactional_tests` is a class attribute
      (created with `class_attribute`) this requires a little bit of hoop
      jumping. The writer method that `class_attribute` generates defines a
      new reader method that return the value being set. Which means we can’t
      set the default of `true` using `use_transactional_tests=` as was done
      previously because that won’t take into account anyone using
      `use_transactional_fixtures`. Instead I defined the reader method
      manually and it checks `use_transactional_fixtures`. If it was set then
      it should be used, otherwise it should return the default, which is
      `true`. If someone uses `use_transactional_tests=` then it will
      overwrite the backwards-compatible method with whatever they set.
      09658635
  13. 15 3月, 2014 1 次提交
  14. 08 11月, 2013 1 次提交
  15. 28 6月, 2013 1 次提交
  16. 15 6月, 2013 1 次提交