[SERVER-32918] Make OplogEntry class useful for partial oplog entries and incremental building Created: 26/Jan/18  Updated: 30/Oct/23  Resolved: 06/Feb/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 3.7.2

Type: Improvement Priority: Major - P3
Reporter: Matthew Russotto Assignee: Siyuan Zhou
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-31356 make OplogEntry immutable Closed
is related to SERVER-32728 SyncTail::syncApply should accept Opl... Backlog
Backwards Compatibility: Fully Compatible
Sprint: Repl 2018-02-12
Participants:

 Description   

The current repl::OplogEntry class is immutable and requires a full oplog entry with all required fields such as oplog timestamp, hash, and version. For the transactions project we will sometimes need a representation of partial oplog entries (in particular, the subops of applyOp) and will sometimes need to build oplog entries incrementally (so, e.g., the optime can be set later).

We will need to

1) Change the IDE for OplogEntryBase so all fields (except possibly opType) are optional, and the structure is no longer immutable.

2) Move the checks for the required fields into the parse() and toBson() methods on OplogEntry.

3) Create separate methods which allow partial parsing and toBson without checking all the fields.

4) Use "const OplogEntry" in existing uses where immutability is desired.



 Comments   
Comment by Githook User [ 09/Feb/18 ]

Author:

{'email': 'siyuan.zhou@mongodb.com', 'name': 'Siyuan Zhou', 'username': 'visualzhou'}

Message: SERVER-32918 Set OpType in ReplOperation maker helpers.
Branch: master
https://github.com/mongodb/mongo/commit/0179e8ad4d2232271a6ce26b13b619690aca95be

Comment by Githook User [ 06/Feb/18 ]

Author:

{'email': 'siyuan.zhou@mongodb.com', 'name': 'Siyuan Zhou', 'username': 'visualzhou'}

Message: SERVER-32918 Extract operation fields of OplogEntryBase into chained ReplOperation.
Branch: master
https://github.com/mongodb/mongo/commit/603ffac833b945fddf962fc450c65bb67c7733a1

Comment by Githook User [ 06/Feb/18 ]

Author:

{'email': 'siyuan.zhou@mongodb.com', 'name': 'Siyuan Zhou', 'username': 'visualzhou'}

Message: SERVER-32918 IDL chained structs expose their getters and setteres.

Author: Mark Benvenuto
Branch: master
https://github.com/mongodb/mongo/commit/a03293b4bd08fa2b197ce75b94d2ad158884919e

Comment by Benety Goh [ 26/Jan/18 ]

Perhaps similar to what we do for BSONObj, we can consider having some kind of OplogEntryBuilder?

Comment by Judah Schvimer [ 26/Jan/18 ]

benety.goh recently made this immutable in SERVER-31356. This directly contradicts that. I think that was done because we were using the "raw" field in certain places, and that didn't change with mutations. I think using OplogEntry safely everywhere would be a prerequisite for this ticket.

Generated at Thu Feb 08 04:31:42 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.