[DRIVERS-1186] Allow db/collection/index enumeration to respect read preference Created: 30/Apr/18 Updated: 15/Mar/22 Resolved: 14/Mar/22 |
|
| Status: | Closed |
| Project: | Drivers |
| Component/s: | Server Selection |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | A. Jesse Jiryu Davis | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | leads-triage | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Driver Changes: | Not Needed | ||||||||||||
| Description |
|
There's a section in the spec that says listCollections and some other commands that read should go to the primary, ignoring read preference. There's no justification written that I can find. If we relax this and say that all commands that read obey read preference, it simplifies existing specs and removes a contradiction from the Transactions spec. (If we leave "should-use-primary" in place, then there's a problem when you run listCollections in a transaction that was begun with read preference secondary.) |
| Comments |
| Comment by Benji Rewis (Inactive) [ 11/Mar/22 ] | |||
|
This came up again recently in the Go driver with GODRIVER-2317. I think it would be worth considering honoring the user's readPreference for at least the list* commands (or maybe even using primaryPreferred instead of just primary). | |||
| Comment by Jeffrey Yemin [ 03/Aug/20 ] | |||
|
Thanks, Jesse. Closing as Won't Fix until we hear user pain with the current behavior. | |||
| Comment by A. Jesse Jiryu Davis [ 03/Aug/20 ] | |||
|
I definitely have zero opinion about this now! Please close, or implement the change, or do whatever you prefer. | |||
| Comment by A. Jesse Jiryu Davis [ 08/May/18 ] | |||
|
If you use runCommand for a command that drivers provide helpers for, you're on your own. That's a core principle of all our specs. You can cause problems executing this too:
However, I think I agree with you in this case that runCommand is the one exception to the change I proposed. Let's keep it as "should-use-primary". | |||
| Comment by Jeffrey Yemin [ 08/May/18 ] | |||
|
Won't changing runCommand semantics break compatibility? Consider
Currently this will execute on the primary no matter the read preference, but this change would make it a read operation and execute on a secondary when the database's read preference is secondary. | |||
| Comment by A. Jesse Jiryu Davis [ 30/Apr/18 ] | |||
|
Let's start the list here:
Anything else? We've long since decided that drivers obey read preference for mapreduce and aggregate regardless of their parameters. | |||
| Comment by David Golden [ 30/Apr/18 ] | |||
|
The justification is that "they are intended to be run against primaries but would succeed against secondaries". My recollection is that we felt that some things shouldn't be run against secondaries but that the server didn't historically prohibit it and we wanted to avoid users shooting themselves in the foot. Though for all I know it was added only to accommodate existing specs. I have no strong feelings and I like simplification. Do you have the complete list of commands to which this applies so we know what's affected? |