[CDRIVER-3328] Provide a way to access the URI updated with TXT records from a mongoc_client_t Created: 21/Aug/19 Updated: 27/Oct/23 Resolved: 14/Jan/20 |
|
| Status: | Closed |
| Project: | C Driver |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kaitlin Mahar | Assignee: | Kevin Albertson |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Description |
|
When a user uses creates a mongoc_client_t via a URI that specifies values via TXT record, the URI stored on the mongoc_client_t is not updated according to the records – per this line in the DNS tests it appears only the topology's copy is. Since the topology is not publicly accessible, this makes it impossible for the Swift driver to e.g. get an accurate picture of the options set on a URI or to fully implement the initial DNS seedlist discovery spec tests. |
| Comments |
| Comment by Githook User [ 14/Jan/20 ] |
|
Author: {'name': 'Kevin Albertson', 'email': 'kevin.albertson@mongodb.com', 'username': 'kevinAlbs'}Message: |
| Comment by Kaitlin Mahar [ 10/Jan/20 ] |
|
kevin.albertson Testing this out, I do see values that are only provided via TXT are showing up when I call the corresponding getters on the URI. I thought I had actually tested that before to confirm they did not show up, but apparently not. Thanks for looking into this! |
| Comment by Kevin Albertson [ 10/Jan/20 ] |
|
kaitlin.mahar Looking into this, it appears the uri stored on the mongoc_client_t actually is updated after initial seedlist discovery (though it won't be updated during SRV polling, it should still get the new hosts and options from the initial SRV + TXT requests when constructing a client). The change in The comment in the DNS tests seems to be outdated. I'll update that test shortly. But otherwise, I believe there is no required change here. But let me know if I'm missing something. |
| Comment by Kaitlin Mahar [ 25/Aug/19 ] |
|
That would work fine for our purposes. |
| Comment by Jeremy Mikola [ 23/Aug/19 ] |
|
Is there a particular reason to keep the client's URI separate from the topology? In lieu of introducing a new API, I wonder if we could instead have mongoc_client_get_uri delegate to the topology (assuming that's always the most up-to-date struct). Is there value in preserving the original URI used to construct the client? If users needed a copy of that, I suppose they could fetch it immediately after creating/popping a client and copy it before it might be updated by SRV polling at a later point. |
| Comment by Kaitlin Mahar [ 22/Aug/19 ] |
|
Implementing these tests is the first time we've run into a need for this. That said, In the future we may provide a similar API to mongoc and allow a user to retrieve a MongoClient 's originating ConnectionString. Regarding the tests, In general, I believe it's beneficial for us to implement spec tests that check behavior encapsulated within mongoc. We've discovered mongoc bugs in the past via our runners that test mongoc logic. For example, change stream resumability is handled by mongoc, but implementing tests for that found |
| Comment by Kevin Albertson [ 22/Aug/19 ] |
|
Is this only necessary to implement tests in Swift? I don't know if we've added public API only for the sake of making test assertions for wrapper drivers. Since resolution of SRV/TXT records is contained in libmongoc, perhaps wrapping drivers should not be required to implement these tests? |