[SERVER-72500] Create and implement the ApplierOperation wrapper class for oplog applier Created: 04/Jan/23 Updated: 29/Oct/23 Resolved: 10/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: | Wenbin Zhu | Assignee: | Daniel Gottlieb (Inactive) |
| 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: | Repl 2023-01-09 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
The ApplierOperation class would be a wrapper class over OplogEntry as dedicated in the design doc. It would contain information to differentiate normal oplog entries from split prepared entries. Oplog applier will add ApplierOperation instances into writerVectors instead of raw OplogEntry instances. |
| Comments |
| Comment by Githook User [ 10/Jan/23 ] |
|
Author: {'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}Message: ApplierOperations in the general case decays to an OplogEntry. But they can also encapsulate states |