The Stitch library scope document allocates time for refactoring as part of its implementation plan, and it specifically calls out the dependency between ProjectionExec and WorkingSetMember:
Separate the core functionality from other parts of the system, e.g. ProjectionExec currently depends on WorkingSet, RecordId, etc.
The PoC implementation of this work is able to work around this dependency by creating its own WorkingSetMember objects. My conclusion from implementing the workaround in the PoC is that it's completely reasonable for use in the production implementation.
We can still consider refactoring this dependency, though, if we think it would improve the overall cleanliness of our architecture.
- related to
-
SERVER-38695 Make QuerySolutionNode subclasses for projection fast-paths
- Closed