[SERVER-63202] IDL-ize RenameCollectionOptions Created: 02/Feb/22  Updated: 26/Oct/23

Status: Blocked
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Pierlauro Sciarelli Assignee: Backlog - Catalog and Routing
Resolution: Unresolved Votes: 0
Labels: neweng, oldshardingemea, sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-65865 Support multi-level chained structs Open
Assigned Teams:
Catalog and Routing
Sprint: Sharding EMEA 2022-05-16
Participants:

 Description   

The definition of rename collection options is currently duplicated in rename_collection.h and in sharded_ddl_commands.idl. That means that any change must be mirrored in both files.

Objective of this ticket is to extract a common IDL type to import in rename_collection.h and to include as chained struct in the sharded command.



 Comments   
Comment by Silvia Surroca [ 17/May/22 ]

Both structs share 4 fields but differ in one field each one as is shown in the following table:

RenameCollectionRequest RenameCollectionOptions
to -
dropTarget dropTarget
stayTemp stayTemp
expectedSourceUUID expectedSourceUUID
expectedTargetUUID expectedTargetUUID
- markFromMigrate

To avoid duplicities a solution is to create a new struct with the 4 fields in common and then inherit it to get both existing structs adding the extra fields (to for RenameCollectionRequest and markFromMigrate for RenameCollectionOptions)

Trying that we bumped into an IDL compiler limitation (SERVER-65865) that doesn't allow to have more than one nested struct.

Generated at Thu Feb 08 05:57:08 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.