[SERVER-28962] RenameCollection oplog entry field dropTarget can have 2 types Created: 25/Apr/17  Updated: 27/Oct/23  Resolved: 03/Jan/20

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

Type: Improvement Priority: Major - P3
Reporter: Judah Schvimer Assignee: Backlog - Replication Team
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Replication
Participants:

 Description   

The Collection Versioning design proposes changing the dropTarget field of the RenameCollection oplog entry to potentially be a boolean and potentially be a UUID. This will make it difficult to parse and handle RenameCollection oplog entries wherever we need to. One suggestion to make this easier is to split this into two fields, one that is a boolean, dropTarget, and one that is a UUID, dropTargetUUID, where the UUID field only exists if the boolean dropTarget field is true. Adding new fields is generally easier because older versions can just ignore them.



 Comments   
Comment by Judah Schvimer [ 03/Jan/20 ]

I'm fairly sure this went away with SERVER-34196. Either way it's not a pain point now.

Comment by Geert Bosch [ 12/May/17 ]

judah.schvimer and I decided to go with the wrapper approach. This workaround can be removed once we drop support for upgrading from MongoDB 3.4 and older.

Comment by Judah Schvimer [ 25/Apr/17 ]

An alternative to changing the field would be to create a wrapper around RenameCollection that handles the two types. We could also make a boolean parse to a special UUID value and handle it in the IDL (https://github.com/mongodb/mongo/blob/master/src/mongo/idl/unittest.idl#L68-L82), though I think the wrapper is a better solution.

Comment by Geert Bosch [ 25/Apr/17 ]

If we decide we only need dropTarget in the oplog entry if the target has a UUID, that would be a nice simplification.

Comment by Andy Schwerin [ 25/Apr/17 ]

What's the point of the dropTarget boolean value in the oplog entry in 3.4 and prior? The secondary oplog application process would have to ignore it, anyways.

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