[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:
Depends
Related
is related to GODRIVER-2317 ListCollections failed Closed
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:

runCommand({abortTransaction: 1})

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

 
database.runCommand({insert: "test", documents : [{}] })

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:

  • listCollections (Enumerating Collections spec and Server Selection spec)
  • listDatabases (Enumerating Databases spec)
  • listIndexes (Enumerating Indexes spec)
  • runCommand (Server Selection spec: don't inherit read pref from database, but allow read pref as a parameter)

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?

Generated at Thu Feb 08 08:23:00 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.