[CDRIVER-2817] Are duplicates for all URI options parsed consistently? Created: 07/Sep/18 Updated: 28/Oct/23 Resolved: 21/Sep/18 |
|
| Status: | Closed |
| Project: | C Driver |
| Component/s: | docs, uri |
| Affects Version/s: | None |
| Fix Version/s: | 1.14.0 |
| Type: | Task | Priority: | Minor - P4 |
| Reporter: | Jeremy Mikola | Assignee: | Unassigned |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
If the same option appears multiple times in a connection string (e.g. connectTimeoutMS) with either the same or different spellings, how is its value stored and later retrieved? Does the last occurrence always take precedence? Furthermore, is behavior consistent for special URI options that may a struct field (e.g. auth or SSL options) and generic options that set a key in the bson_t within a URI struct and are later looked up with a generic get method (e.g. connectTimeoutMS)? For context, the connection string spec states:
|
| Comments |
| Comment by Githook User [ 21/Sep/18 ] | ||||||||
|
Author: {'name': 'Kevin Albertson', 'email': 'kevin.albertson@10gen.com', 'username': 'kevinAlbs'}Message: | ||||||||
| Comment by Githook User [ 20/Sep/18 ] | ||||||||
|
Author: {'name': 'Kevin Albertson', 'email': 'kevin.albertson@10gen.com', 'username': 'kevinAlbs'}Message: | ||||||||
| Comment by Kevin Albertson [ 13/Sep/18 ] | ||||||||
|
We make an effort to replace the existing value when parsing a duplicate option.
Uses "w=2". We also log a warning every time we overwrite w:
So for most cases, the last value takes precedence. The helper functions which set the option on the mongoc_uri_t
Attempt to replace the option value whenever seeing a duplicate. However, in digging around there seems to be at least some exceptions. For instance, a string value for "w" will replace an integer value for "w" but not vice-versa:
Uses w=majority
Uses w=majority (but should use w=0 for consistency) Repeated readpreferencetags don't overwrite, but instead get appended
Sets the tags to a:1, b:1 I haven't tested all cases, but I think these are the only exceptions. | ||||||||
| Comment by A. Jesse Jiryu Davis [ 13/Sep/18 ] | ||||||||
|
To close this ticket, answer the question here and note in an appropriate place in the docs that repeated values have undefined behavior. |