The PlanExecutor interface is currently the mechanism by which all CRUD operations except for insert are executed. (The fact that PlanExecutor is not used for inserts is surprising, and should probably be corrected either as part of this ticket or as its own work item.) This interface, however, is biased towards execution that produces a stream of documents. It features methods like getNext() which are used to get either the next document in the stream or EOF. This is useful for commands like find and aggregate, as well as for internal callers that scan indexes or collections. However, it is not a useful interface for non-cursor CRUD operations, such as update, delete, count, distinct, and so on.

We should split up the PlanExecutor interface into multiple interfaces that better match the needs of callers. One idea would be to structure a hierarchy of interfaces like so:

• PlanExecutor
  • PlanExecutorCursor
    • PlanExecutorImpl
    • PlanExecutorSBE
    • PlanExecutorPipeline
  • PlanExecutorCount
  • PlanExecutorDelete
  • PlanExecutorUpdate
  • ...

Here, the getNext() method and other cursor-related methods would be moved down into the PlanExecutorCursor interface. Most of the pre-existing PlanExecutor implementations would now instead implement PlanExecutorCursor, including PlanExecutorImpl for classic PlanStage execution, PlanExecutorPipeline for DocumentSource execution, and PlanExecutorSBE. There would then be separate interfaces with new implementations for all the non-cursor commands. One challenge with this approach is having some kind of code sharing arrangement between implementations of the various new CRUD interfaces, as a lot of the logic around things like yielding and explain is common for all CRUD commands.

Another idea of how to restructure the interface comes from anton.korshunov. He suggests splitting the interface into two, one called PlanExecutor for reads and another called ModificationPlanExecutor for writes. The PlanExecutor would offer methods for executing find, aggregation, count, and so on, whereas the ModificationPlanExecutor would offer methods for executing deletes, updates, and inserts.