[SERVER-44882] QueryRequest::_readConcern might be better as a ReadConcernArgs Created: 29/Nov/19  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Kevin Pulo Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 0
Labels: qopt-team
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-43712 Use RWCDefaults for incoming requests... Closed
Assigned Teams:
Query Optimization
Backwards Compatibility: Fully Compatible
Participants:

 Description   

Recently on SERVER-43712 there was a need to update QueryRequest to distinguish between absent (unspecified) readConcern, and readConcern which is an empty sub-object.

This was done by changing _readConcern from BSONObj to boost::optional<BSONObj>, but this results in some awkwardness when preserving the getReadConcern() return value of const BSONObj& (because return _readConcern.value_or(BSONObj()); would return a reference to a temporary), and other awkwardness when interacting with the readConcern on the opCtx.

An alternative would be to keep _readConcern as BSONObj and have a bool _readConcernHasBeenSet = false; alongside it. But this would be ugly and clunky in other ways, by having to maintain and coordinate these tandem variables.

It might be better if _readConcern was updated to be of type ReadConcernArgs instead, since this is the more natural representation of read concern (eg. it can easily and correctly distinguish between unspecified and empty readConcerns).


Generated at Thu Feb 08 05:07:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.