Details
-
Task
-
Resolution: Duplicate
-
Major - P3
-
None
-
None
-
None
-
Sharding
Description
Original Ticket:
In build(Un)versionedRequestsFor(All)TargetedShards that are used in explains count and distinct
same thing as in cluster find and aggregate commands - look how it can reuse the code.
in cluster_commands_helpers.cpp
Summary:
Given a BSON command object with readConcern level snapshot, replace its snapshot readConcern with a new snapshot readConcern with atClusterTime. Since the cmd obj already has a readConcern field, the object will be iterated over, copying all of its fields that are not readConcern, then the new readConcern will be appended at the end.
Details:
BSONObj appendAtClusterTime(BSONObj cmdObj, LogicalTime atClusterTime) {
|
// Append all original fields except the readConcern field to the new command.
|
BSONObjBuilder bob;
|
for (auto elem : cmdObj) {
|
const auto name = elem.fieldNameStringData();
|
if (name != "readConcern") {
|
bob.append(elem);
|
}
|
}
|
|
|
// Add the new snapshot readConcern with atClusterTime.
|
BSONObjBuilder readConcernBob(bob.subobjStart("readConcern"));
|
readConcernBob.append("level", "snapshot");
|
readConcernBob.append("atClusterTime", atClusterTime.asTimestamp());
|
readConcernBob.doneFast();
|
|
|
return bob.obj();
|
}
|
Open Questions:
- Can appendAtClusterTime receive a cmdObj with no readConcern?
- It should have readConcern: "snapshot" to trigger the GPITR code, so I don't think so.
Unit tests:
- Given a BSONObj with each readConcern level, verify appendAtClusterTime overwrites the existing level
Attachments
Issue Links
- duplicates
-
SERVER-33062 Amend command with readConcern atClusterTime
-
- Closed
-