Improved timestamps option handling in bulkWrite #14546
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #14536
Summary
There's a fairly inconsistent experience with the
timestamps
option inbulkWrite
right now:insertOne
operations is by specifyingtimestamps
in the the top-levelbulkWrite
optionsupdateOne
andupdateMany
have theirtimestamps
option set purely at the operation leveltimestamps
option forreplaceOne
operationsLet's debate desired behavior here, but this PR introduces a hierarchy in order to (mostly) prevent breaking changes:
timestamps
is specified within a given operation (e.g.,op.updateOne.timestamps
), then use ittimestamps
setting in the top-levelbulkWrite
options and use it if it existstrue
Pros
insertOne
is fully controlled by a different level thanupdateOne
andupdateMany
. But it's not 100% non-breaking (see below)bulkWrite
commands. I've run into this scenario myself, so I understand the benefitCons
bulkWrite
with a mix ofinsertOne
andupdateOne
commands, you currently controlinsertOne
at the top level andupdateOne
at the operation level. Suppose you want to set timestamps for allupdateOne
commands but NOT for anyinsertOne
commands. You would do that today by NOT specifying anything fortimestamps
in theupdateOne
commands and specifyingtimestamps: false
in the top-level options. Moving forward, with this PR as written, the samebulkWrite
will no longer set timestamps on anything.Alternatives
insertOne.timestamps
andreplaceOne.timestamps
options. But we need to leave the top-leveltimestamps
option in order to not breakinsertOne
timestamp control for existing users. This will remain an inconsistent experience, as top-level will only controlinsertOne
commandstimestamps
altogether and just doingtimestamps
specification at the command level for all command types. Since it's a breaking change, delay landing this until 9.Xtimestamps
option forbulkWrite
has never been officially documented, so we can remove it without it being a breaking change. AddinsertOne.timestamps
andreplaceOne.timestamps
options, and ship with 8.X. Honestly this is probably the optimal outcome from a simplicity/consistency/speed perspective...Conclusion
After writing out everything above, I'm thinking my current solution as written is the worst of both worlds! Out of the alternatives listed above, I'm partial to alternative 3, but I don't know how others think about the argument that removing top-level
timestamps
is non-breaking.