[SERVER-72419] Refactor applySideWrite interface Created: 28/Dec/22 Updated: 29/Oct/23 Resolved: 03/Jan/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.3.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Ian Boros | Assignee: | Dianna Hohensee (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | pm2646-m5 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Backwards Compatibility: | Fully Compatible |
| Participants: |
| Description |
|
The IndexAccessMethod contains separate interfaces for applying side writes to btree indexes and columnar indexes. This means that IndexAccessMethod is "aware" of its children in the inheritance tree. There is only one caller, which knows which type of IAM it is working with. This ticket is to remove IndexAccessMethod::applySideWrite* functions and have the caller cast to the appropriate access method and use that directly. |
| Comments |
| Comment by Githook User [ 30/Dec/22 ] |
|
Author: {'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@mongodb.com', 'username': 'DiannaHohensee'}Message: |
| Comment by Dianna Hohensee (Inactive) [ 29/Dec/22 ] |
|
Notes: I think there's a greater layer violation going on wherein IndexBuildInterceptor, for unique indexes, tracks (potentially temporary) duplicate keys via the DuplicateKeyTracker and then passes it down into the IndexAccessMethod for special handling. One could argue that the IndexAccessMethod should only support access to a single index table, not also support the duplicate key table, and that the duplicate key table is the IndexBuildInterceptor class' business. But that's talking ideals. The current code is quite serviceable. But rather than exposing IndexAccessMethod implementation types in IndexBuildInterceptor, I'd opt for unifying the IndexAccessMethod interface with a single side writes function that takes some parameters that the ColumnAccessMethod will not use. |