[GODRIVER-556] mongo.Client should provide topology type Created: 15/Sep/18  Updated: 27/Mar/23  Resolved: 27/Mar/23

Status: Closed
Project: Go Driver
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: David Golden Assignee: Kevin Albertson
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by TOOLS-1833 Migrate tools (excluding mongoreplay)... Closed
Related
related to GODRIVER-41 Implement SDAM Monitoring specification Closed
related to JAVA-3307 Add getClusterDescription method to M... Closed
Documentation Changes Summary:

1. What would you like to communicate to the user about this feature?
2. Would you like the user to see examples of the syntax and/or executable code and its output?
3. Which versions of the driver/connector does this apply to?


 Description   

Mongo tools, in particular, often need to know the topology type they are connecting to.  Rather than calling RunCommand with 'ismaster' and parsing the results, the Client object should provide a method to retrieve the topology type.



 Comments   
Comment by Thomas Zembowicz [ 20/Mar/23 ]

esha.bhargava@mongodb.com thanks for the ping. While a Topology() method would be nice I think using SDAM events (TopologyDescriptionChanged) is a totally fine workaround and would be an improvement over how ADF is determining topology today.

Comment by David Golden [ 07/Mar/23 ]

I defer to thomas.zembowicz@mongodb.com as we may have a different desired workaround.

Comment by Kevin Albertson [ 07/Mar/23 ]

I prefer not to add a getter for description.Topology to the API. IMO this is not a common use case for the average user.
 
Is creating a TopologyDescriptionChanged listener sufficient? Example:
 

var latestTD *description.Topology
var lockTD sync.RWMutex
 
client, err := mongo.Connect(context.TODO(), options.Client().ApplyURI(uri).SetServerMonitor(
	&event.ServerMonitor{
		TopologyDescriptionChanged: func(tdce *event.TopologyDescriptionChangedEvent) {
			lockTD.Lock()
			defer lockTD.Unlock()
			latestTD = &tdce.NewDescription
		},
	},
))

 
Here is a runnable example.
 

Comment by Kristofer Brandow (Inactive) [ 24/Sep/18 ]

I don't a problem with doing this. We can provide whatever the type that the topology.Topology has.

Comment by David Golden [ 17/Sep/18 ]

It is static, even if not immediately useful. When a new topology object is created, it's initialized with a topology description with type "unknown". If a user wants to ensure the topology is discovered, the user can Ping first.

Comment by Jeffrey Yemin [ 17/Sep/18 ]

It's not static data.  The driver doesn't know the topology in all cases until at least one server has responded (asynchronously) to an isMaster command via SDAM.  So the proposed method would have to take a Context and block until it either discovers the topology type or until the Context's deadline is reached.  

 

 

 

Comment by David Golden [ 17/Sep/18 ]

Coding up an event listener is pretty heavyweight to retrieve static data only needed once.  I think all that's needed is handing out a copy of the description.Topology, which is trivial for the driver to provide.  It may not be a common case for applications, but it is a not uncommon case for tests, tools and other command line utilities.

Comment by Jeffrey Yemin [ 16/Sep/18 ]

Once GODRIVER-41 is closed, an application can register an SDAM event listener and determine the topology from the events.  It's a bit more complicated to code, but I also don't imagine this is a common use case.

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