[GODRIVER-2226] Build a Connection String programmatically from connstring.ConnString Created: 12/Nov/21 Updated: 29/Nov/22 Resolved: 29/Nov/22 |
|
| Status: | Closed |
| Project: | Go Driver |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Unknown |
| Reporter: | Rodrigo Valin (Inactive) | Assignee: | Matt Dale |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Epic Link: | GODRIVER-1588 | ||||||||||||
| Quarter: | FY23Q3 | ||||||||||||
| Description |
|
We would like to be able to programmatically create a Connection String from a struct like connstring.ConnString. Ideally we could use a builder pattern in order to do:
In the previous example, builder.Build() would return a concrete ConnString that can be called with ToURI() to obtain a valid connection string. The builder part is just an example, a ConnString object with a function like ToURI() or ToString() is what we really need. How that ConnString is constructed can be done on our side. Our particular use case (Kubernetes Operators) is that we create Connection Strings in Secret Kubernetes objects that users could mount into their client applications. Currently we do this with a series of error-prone fmt.Sprintf() function calls. We have two examples in Community Operator using fmt.Sprintf() to build connection strings:
And there are more in Enterprise and Atlas Operators as well. |
| Comments |
| Comment by Rajdeep Das (Inactive) [ 29/Nov/22 ] |
|
Hey matt.dale@mongodb.com , makes sense and thanks for the detailed explanation. |
| Comment by Matt Dale [ 29/Nov/22 ] |
|
Hey rajdeep.das@mongodb.com, after considering this more, I don't think the Go driver is the right place to add this functionality. The MongoDB connection string format is based on a specification that all drivers, including the Go driver, implement parsers for. Because the Go driver is not the de-facto standard for the MongoDB connection string format, a connection string builder implemented in the Go driver will not be any more correct than one implemented totally independently of the Go driver (e.g. separate repository, no Go driver dependency). I'm also concerned that a connection string builder implemented in the Go driver would be overly generic and difficult to maintain because the Go driver has no implicit need for it. A more purpose-specific connection string builder would be easier to implement and maintain in a repository that directly depends on it (or a separate repository if necessary to share it between projects). As far as the connstring.ConnString struct in the Go driver, it is only intended to provide the information necessary for the Go driver to connect to a MongoDB deployment, but can not represent every valid MongoDB connection string. For example, the Go driver does not support the tlsAllowInvalidCertificates, tlsAllowInvalidHostnames, waitQueueMultiple, or waitQueueTimeoutMS connection string options, so the connstring.ConnString struct has no corresponding fields for those. It could be a good starting point for a MongoDB connection string builder, but it's not currently intended for that purpose. TLDR: A MongoDB connection string builder doesn't need to be implemented in the Go driver to be correct. Implementing a connection string builder may actually be easier where it will be used than in the Go driver, which has no use case for it. |
| Comment by Rajdeep Das (Inactive) [ 25/Nov/22 ] |
|
We are wondering if there is any update on this ticket? |
| Comment by Rodrigo Valin (Inactive) [ 16/Nov/21 ] |
|
We need specifically to build a connection string. Take as an example the following Build function: This function was built by us, but it is pretty rough around the edges; and I think we (and others) can benefit from a function provided by the go-driver. We would use this functionality in 3 Operators: Enterprise, Atlas and Community. |
| Comment by Matt Dale [ 15/Nov/21 ] |
|
Is the goal to generate a connection string programatically or to configure a client programatically? My understanding is that most values that can be configured via a connection string can be configured by passing a ClientOptions option, but that there are some missing configurations that can only be applied using mongodb+srv protocol URIs. Would adding the missing ClientOptions configuration values support the use case for the mongodb-kubernetes-operator, or do you specifically need to programatically build a connection string (e.g. to be passed to some other process)? |