Split DocumentSourceExtensionOptimizable into ShapeAware subclass

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Query Integration
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      There are two ways to construct a `DocumentSourceExtensionOptimizable`: directly from a source or transform stage (top-level) or indirectly from a stage that desugars into a source or transform stage.

      The former has a parse node as we are able to go from `stageDescriptor->parseNode->astNode->logicalStage` but the latter doesn't as we only have access to the astNode (and go from astNode->logicalStage).

      The key difference of not having a parseNode during full parse is the inability to get the `queryShape`. This is ok though for the indirect construction case because the top-level desugar stage will be responsibly for `queryShape`.

      Because of this, we should have two classes for `DocumentSourceExtensionOptimizable`: one that is "ShapeAware" with a `parseNode` (`DocumentSourceExtensionOptimizableShapeAware`) and another that only has the `logicalStage` (`DocumentSourceExtensionOptimizable`). `DocumentSourceExtensionOptimizableShapeAware` will derive from the base `DocumentSourceExtensionOptimizable`.

            Assignee:
            Josh Siegel
            Reporter:
            Josh Siegel
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: