fix: honor journal=true in connection string #2354
Conversation
lib/connection_string.js
Outdated
| // special cases for known deprecated options | ||
| if (result.wtimeout && result.wtimeoutms) { | ||
| delete result.wtimeout; | ||
| result.wtimeout = undefined; |
There was a problem hiding this comment.
I know this is counter to what I've said previously, but in these non-critical paths I think there's actual value to outright removing a known bad value. In the future we might solve this by "plucking" all the values we care about into a new object.
|
|
||
| // `journal` should be translated to `j` for the driver | ||
| if (_finalOptions.journal != null) { | ||
| _finalOptions.j = _finalOptions.journal; |
There was a problem hiding this comment.
to me it seems like j is the odd man out here, shouldn't we filter that out and depend on journal throughout the codebase? j is just the field on the command send to the server.
UPDATE: I now see that this is a pretty small change, while what I'm proposing would potentially touch much more of the codebase. Maybe we can defer my suggestion here to @reggi s work on MongoClientOptions
There was a problem hiding this comment.
Yeah I think this is the minimal change necessary to fix this issue; it's probably not worth diving deep on this now when we're already planning on overhauling this entire options system; definitely worth addressing when we do the overhaul.
There was a problem hiding this comment.
btw I think the original report is for 3.5, so we'll need a port there too
…gnored-in-connection-string
3 participants
Description
Ensure the
journaloption returned byparseQueryStringis convertedinto
jduring theconnectoperation. This fixes the issue of thewrite concern not being set on commands where
journalis only specifiedin the connection string.
NODE-2442
What changed?
journalwithjin options duringconnectoperationwithMonitoredClientso it can pass options on tonewClientAre there any files to ignore?