diff options
author | Eileen Uchitelle <eileencodes@gmail.com> | 2019-02-01 11:33:48 -0500 |
---|---|---|
committer | Eileen Uchitelle <eileencodes@gmail.com> | 2019-02-01 14:11:35 -0500 |
commit | 8d32346cdec04dd85ab682eeb9f4edfcd0c9ccef (patch) | |
tree | 35ad1286d0328876eb6e49c61d8ed2044e38f023 /Gemfile.lock | |
parent | 79bc9e81c3d47be6336223be39cb3bcaeddc0a39 (diff) | |
download | rails-8d32346cdec04dd85ab682eeb9f4edfcd0c9ccef.tar.gz rails-8d32346cdec04dd85ab682eeb9f4edfcd0c9ccef.tar.bz2 rails-8d32346cdec04dd85ab682eeb9f4edfcd0c9ccef.zip |
Add ability to change the names of the default handlers
When I wrote the `connected_to` and `connects_to` API's I wrote them
with the idea in mind that it didn't really matter what the
handlers/roles were called as long as those connecting to the roles knew
which one wrote and which one read.
With the introduction of the middleware Rails begins to assume it's
`writing` and `reading` and there's no room for other roles. At GitHub
we've been using this method for a long time so we have a ton of legacy
code that uses different handler names `default` and `readonly`. We
could rename all our code but I think this is better for a few reasons:
- Legacy apps that have been using multiple databases for a long time
can have an eaiser time switching.
- If we later find this to cause more issues than it's worth we can
easily deprecate.
- We won't force old apps to rewrite the resolver middleware just to use
a different handler.
Adding the writing_role/reading_role required that I move the code that
creates the first handler for writing to the railtie. If I didn't move
this the core class would assign the handler before I was able to assign
a new one in my configuration and I'd end up with 3 handlers instead of
2.
Diffstat (limited to 'Gemfile.lock')
0 files changed, 0 insertions, 0 deletions