Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-93539

Split AggExState into AggExState and ResolvedViewAggExState

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

      In the refactored version of runAggregate() we now have a new class called AggExState which holds all the common state needed across the execution of _runAggregate().

       

      However, in the case of running the aggregation command on a resolved view, there the AggExState class needs to be updated and then has some functionality that only applies after the the class is set on a view (such as calling setShardRole). This makes makes the class a superposition of the functionality of running not on a view and a view, (the later of which is a superset of the other). More appropriately, there should be two classes: AggExState and ResolvedViewAggExState, where ResolvedViewAggExState inherits from AggExState, and then adds in the additional functionality it needs for the view case.

       

      Upon first pass, it would seem that runAggregateOnView() would take in a ResolvedViewAggExState and _runAggregate() would take in a AggExState.

            Assignee:
            Unassigned Unassigned
            Reporter:
            joseph.shalabi@mongodb.com Joe Shalabi
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: