[SERVER-33558] Remove read preference from AsyncResultsMerger and $mergeCursors Created: 28/Feb/18 Updated: 29/Oct/23 Resolved: 07/Mar/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework, Querying |
| Affects Version/s: | None |
| Fix Version/s: | 3.7.3 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Charlie Swanson | Assignee: | Charlie Swanson |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Query 2018-03-12 |
| Participants: |
| Description |
|
We believe it is the case that once a cursor is established on a node, the read preference does not play a role. For example, if a read preference "primary" query is sent to the primary and a cursor established, then that cursor can still be iterated if the node steps down between the cursor establishment and the getMore. This means we no longer have to track the read preference during getMores, except in the specific case of new queries issued during getMores, such as described in |
| Comments |
| Comment by Githook User [ 07/Mar/18 ] |
|
Author: {'email': 'charlie.swanson@mongodb.com', 'name': 'Charlie Swanson', 'username': 'cswanson310'}Message: |
| Comment by Charlie Swanson [ 05/Mar/18 ] |
|
Scheduling this for next sprint after discussion in code review. |
| Comment by Charlie Swanson [ 28/Feb/18 ] |
|
I've made a test that proves you can getMore a read preference "primary" cursor even when the node is no longer the primary. |