Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[5.3] Defer resolving read PDO of read/write connection until needed #15031

Merged
merged 2 commits into from
Aug 27, 2016

Conversation

patrickcarlohickman
Copy link
Contributor

This PR updates the read/write connection so that resolving the PDO instance for the read connection is also deferred until it is needed.

When using a single connection for both reads and writes, the PDO instance is not resolved until the connection is actually needed.

When using separate read/write connections, the PDO instance for the write connection is not resolved until needed, but the PDO instance for the read connection is resolved immediately.

This leads to a minor inconsistency of how reading from a single connection works when compared to how reading from a read/write connection works. If one switches from using a single connection to using a read/write connection, one may incur an unexpected increase in connections to the read database.

It is also slightly inconsistent when comparing how the read connection works to how the corresponding write connection works. One may expect that if the write connection is going to be deferred, then the read connection should be deferred, as well.

I could not find a stated reason for this difference, so I thought it may be something open for change. If there is a reason for this difference, I would love to learn, and I apologize for the wasted PR. Additionally, please let me know if anything should be changed, or if this should be targeted at 5.2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants