-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Integration
during deserialization now, $search and $vectorSearch put the view name and resolved view onto the expCtx. This matches the non-sharded logic, which peppers the code with "
expCtx->getViewNSForMongotIndexedView()
" to determine if the documentsource is operating on a view.
However, in the sharded approach, mongos serializes the viewNS and the pipeline. So in createFromBson(), it's not necessary to put it on the expression context bc it's can just be owned by the document source stages themselves.
DocumentSourceSearch::createFromBson(...) {
DocumentSourceSearch::createFromBson(...) { boost::optional<ViewInfo> viewInfo; if (auto view = spec.getView()) { if (auto viewNss = view->getViewNss()) { if (auto pipeline = view->getEffectivePipeline()) { viewInfo = boost::make_optional(ViewInfo(*view->getViewNss(), *pipeline)); } } } else { // In this case we are not parsing a serialized $search from another node. We look on the expCtx if there is a view pipeline. if (expCtx->getViewNSForMongotIndexedView()) { // Do the resolved namespace stuff to populate 'viewInfo' } } }
DocumentSourceSearch should have some sort of boost::optional<viewInfo struct> that contains both the name and pipeline. Then during desugaring, InternalMongotRemote needs to have the view nss and InternalSearchIdLookup needs to have the view pipeline.
We'll need to change the mongot_cursor to be passed the view name, rather than checking expCtx->getViewNSForMongotIndexedView()
- depends on
-
SERVER-96384 support top-level $search/$vectorSearch/$searchMeta queries on sharded views
-
- In Code Review
-