-
Type: Task
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Integration
Two parts here after a thread in the design doc:
> You will have to normalize the read concerns, because the "afterClusterTime" argument's value is going to be different on pretty much every operation with causal consistency enabled. Maybe just change it to indicate that afterClusterTime was supplied, but don't reveal its value (because it would blow out your cache).
"normalize" being our usual 'serializeLiteral' shapification.
> [the telemetry key's read and write concerns] are the user-supplied read- and write-concern, or the system-applied ones? I presume the user-supplied values?
We intend the user-supplied - need to add a test which sets a cluster default (I don't remember how to do that but I'm sure there are other tests and also it is documented), and ensures that the defaulted value does not make it into the telemetry key.
- duplicates
-
SERVER-76919 add gen command fields to query stats key
- Closed
- is depended on by
-
SERVER-85099 Tracking: Milestone 1
- Closed
-
SERVER-85105 Tracking: PM-2885 Milestone 0
- Closed
- related to
-
SERVER-76919 add gen command fields to query stats key
- Closed
-
SERVER-85717 Shapify readConcern's 'atClusterTime' parameter
- Closed