-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Execution
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
While discussing the proposal of caching FCV value in ExpCtx in slack (ref), justin.seyster@mongodb.com pointed out that SPM-4048 project is adding VersionContext class that is designed to cache the FCV value, which should be accessed throughout the lifetime of the query/cursor
We should do the same and store it ExpressionContext. We should also get rid of feature flag cached values.
—
Original Proposal (slack ref):
While looking at ExpressionContext, I noticed that we use the relatively recently introduced utility Deferred, which is great (kudos to @james.harrison) to cache feature flag values. Here is a list of some of the cached feature flags (ref).I believe that rather than caching the values of individual feature flags, we should just cache the value of the FCV for the lifetime of the query.
This way we have:
- same behavior
- cache only a single value (FCV)
- don't pollute the ExpressionContext and
- avoid unnecessary changes in the ExpressionContext file when adding/removing the feature flag (git noise).
Potentially all feature flag values should be read from the cached FCV value available in ExpCtx, if possible (if ExpCtx is created and accessible from that place in code).
Proposal:
- Cache FCV value snapshot in ExpCtx
- Do not cache feature flag values in ExpCtx or other places in code
- Enforce feature flag readers to pass cached FCV value from ExpCtx
- We could try doing this by introducing a linting rule, where one can not read the feature flag value by passing the FCV value serverGlobalParams.featureCompatibility.acquireFCVSnapshot(), unless a comment is placed explaining why we bypass the linting rule