[SERVER-76262] Consider refactoring the collation logic of IDHACK solution for delete command into ParsedDelete Created: 18/Apr/23 Updated: 14/Nov/23 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Yoon Soo Kim | Assignee: | Colin Stolley |
| 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: | |||||
| Description |
|
This is a refactoring ticket. Currently we don't go through the normal query parsing logic of ParsedDelete for IDHACK solution for delete command inside ParsedDelete::parseRequest(). Instead, we manually compose IDHACK plan inside getExecutorDelete(). As part of this process, we figure out the collator to use. Given that recently timeseries arbitrary updates/deletes project added a collator resolution logic, we should be able to reuse ParsedDelete's expCtx's collator for IDHACK plan too. Probably we may want to IDHACK eligibility check into ParsedDelete too and add isIDHackEligible() method and only do the final step like creating IDHackStage and generate the IDHACK plan inside getExecutorDelete() |
| Comments |
| Comment by Xuan Zhang [ 14/Nov/23 ] |
|
Given your recent work on IDHack, could you please help evaluate if this fits in your current work or PM-3386? Feel free to send it back to backlog if it doesn't fit. Thanks! |