[SERVER-37831] Optionally decouple WorkingSetMember from projection evaluation Created: 30/Oct/18 Updated: 29/Oct/23 Resolved: 28/Dec/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.7 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Justin Seyster | Assignee: | Jacob Evans |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Query 2018-12-03, Query 2018-12-17, Query 2018-12-31, Query 2019-01-14 | ||||||||
| Participants: | |||||||||
| Description |
|
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. |
| Comments |
| Comment by Githook User [ 28/Dec/18 ] |
|
Author: {'email': 'jacob.evans@10gen.com', 'name': 'Jacob Evans'}Message: |
| Comment by David Storch [ 16/Nov/18 ] |
|
charlie.swanson jacob.evans seems reasonable to me! I'd like to be on the code review for this work. |
| Comment by Charlie Swanson [ 15/Nov/18 ] |
|
justin.seyster and david.storch it looks like Jacob's two other Stitch Lib tickets are blocked on |