[SERVER-31695] Support queries across collection renames Created: 24/Oct/17 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Querying, Replication, Storage |
| Affects Version/s: | 3.6.0-rc0 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Matthew Russotto | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Assigned Teams: |
Query Execution
|
||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Linked BF Score: | 5 | ||||||||||||||||||||||||||||
| Description |
|
When we are querying a collection during initial sync, we do the initial find by UUID. However, subsequent getMore commands are done by name, which is a problem if the collection is renamed. We cannot distinguish a dropped collection from a renamed one because in the getMore has only the old name and thus cannot look up the collection or the cursor. |
| Comments |
| Comment by David Storch [ 07/Feb/19 ] |
|
Moving back to "Needs Scheduling". Much of the prep-work for this improvement has been completed now that all ClientCursor objects are managed by the global cursor manager. We should re-evaluate its priority. |
| Comment by Andy Schwerin [ 14/Nov/17 ] |
|
This makes renames kill initial syncs, so I'd like to think about how we can get past this in the future. It might make sense to consider this goal when revisiting the storage apis to support the multi-versioned collection catalog. Please re-triage. |
| Comment by Geert Bosch [ 03/Nov/17 ] |
|
The bigger issue is that currently client cursors are killed when a collection is renamed. They have to be because the actual Collection object is destructed, and it has the cursor manager which owns the client cursors. Changing this would require major query system work and is definitely out of scope for 3.6. As you indicate there are also issues during yielding which any getMore changed wouldn't fix. So, instead, when a collection is renamed while it is being cloned, we should simply retry the clone (up to a small constant number of times). |
| Comment by Eric Milkie [ 25/Oct/17 ] |
|
matthew.russotto spencer could you be more specific about what you would like the new behavior of the getMore command to be? |
| Comment by Spencer Brody (Inactive) [ 24/Oct/17 ] |
|
This would need to happen to allow initial syncs to be resilient to collection drops on the sync source. |