[DRIVERS-2163] Use server description to determine feature support Created: 22/Jan/20  Updated: 08/Jan/24

Status: Backlog
Project: Drivers
Component/s: None
Fix Version/s: None

Type: Spec Change Priority: Minor - P4
Reporter: Oleg Pudeyev (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
Driver Changes: Needed

 Description   

As part of work on unifying behavior around configuration for replica set discovery, we discussed that the drivers should be using server description of the server to which an operation would be sent to determine whether the operation would be supported, rather than topology type. For example, if a driver is connected to a replica set member in Single topology, retryable reads and writes, sessions and transactions should be supported because the underlying server supports them.

This ticket covers spec changes across existing specifications explicitly stating that the feature detection should be based on server description, not topology type.

According to my investigation the following specifications should be examined for possible changes/clarifications:

Enumerate-collections - listCollections on replica set members
Enumerate-indexes - listIndexes on replica set members
Enumerate-databases - listDatabases on replica set members
Driver-read-preference - command helpers and secondaries
Causal-consistency - test cases
Retryable-writes - supported server versions
Retryable-reads - supported server versions
Sessions - how to determine whether deployment supports sessions
Transactions - startTransaction - server support of transactions



 Comments   
Comment by Jeffrey Yemin [ 26/Feb/20 ]

Additionally, drivers should make sure they use the server description derived from the actual connection that it's using for the operation rather than the server description from the topology. This has two benefits:

  1. The wire version from the connection should be up to date, since (at least currently) the wire version of a server doesn't change during the lifetime of a connection, so we know that any operation on a connection will be using an up to date wire version instead of a potentially stale one from the topology
  2. It sets us up for drivers to connect to a load balancer, where each connection to the load balancer could be bound to a different mongo server, each with its own wire version.

CC mira.carey@mongodb.com

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