aboutsummaryrefslogtreecommitdiffstats
path: root/activesupport/lib/active_support/ordered_hash.rb
diff options
context:
space:
mode:
authoreileencodes <eileencodes@gmail.com>2019-04-05 12:09:15 -0400
committereileencodes <eileencodes@gmail.com>2019-04-08 14:45:49 -0400
commitb7cc1eb658dbc0569a9a43c7bf6a89c18d934837 (patch)
tree754ae1cd3df1d536633023321ff43376d3c69eaa /activesupport/lib/active_support/ordered_hash.rb
parent61073e3190fe149ed5bf46c8f10276a2a7155112 (diff)
downloadrails-b7cc1eb658dbc0569a9a43c7bf6a89c18d934837.tar.gz
rails-b7cc1eb658dbc0569a9a43c7bf6a89c18d934837.tar.bz2
rails-b7cc1eb658dbc0569a9a43c7bf6a89c18d934837.zip
Ensure a handler is set when using `connected_to`
After looking at #35800 there is definitely an issue in the `connected_to` method although it's generally behaving. Here are the details: 1) I added a default connection role - writing - to the connection handler lookup. I did this because otherwise if you did this: ``` connected_to(databse: :development) ``` And development wasn't a pre-established role it would create a new handler and connect using that. I don't think this is right so I've updated it to pick up the default (:writing) unless otherwise specified. To set a handler when using the database version pass a hash like you would to `connects_to`: ``` connected_to(database: { readonly_slow: :development }) ``` This will connect the `development` database to the `readonly_slow` handler/role. 2) I updated the tests to match this behavior that we expect. 3) I updated the documentation to clarify that using `connected_to` with a `database` key will establish a new connection every time. This is exactly how `establish_connection` behaves and I feel this is correct. If you want to only establish a connection once you should do that in the model with `connects_to` and then swap on the role instead of on the database hash/key. 4) In regards to #35800 this fixes the case where you pass a symbol to the db and not a hash. But it doesn't fix a case where you may pass an unknown handler to an abstract class that's not connected. This is tricky because technical AbstractFoo doesn't have any connections except for through ApplicationRecord, so in the case of the application that was shared we should only be swapping connections on ActiveRecord::Base because there are no other actual connections - AbstractFoo isn't needed since it's not establishing a new connection. If we need AbstractFoo to connect to a new handler we should establish that connection with the handler in AbstractFoo before trying to shard there.
Diffstat (limited to 'activesupport/lib/active_support/ordered_hash.rb')
0 files changed, 0 insertions, 0 deletions