diff options
author | eileencodes <eileencodes@gmail.com> | 2019-04-05 12:09:15 -0400 |
---|---|---|
committer | eileencodes <eileencodes@gmail.com> | 2019-04-08 14:45:49 -0400 |
commit | b7cc1eb658dbc0569a9a43c7bf6a89c18d934837 (patch) | |
tree | 754ae1cd3df1d536633023321ff43376d3c69eaa /actionpack/test/dispatch/callbacks_test.rb | |
parent | 61073e3190fe149ed5bf46c8f10276a2a7155112 (diff) | |
download | rails-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 'actionpack/test/dispatch/callbacks_test.rb')
0 files changed, 0 insertions, 0 deletions