[SERVER-58570] Add a new field to config.collections/config.cache.collections representing whether a collection supports long names Created: 15/Jul/21  Updated: 29/Oct/23  Resolved: 06/Aug/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 5.1.0-rc0

Type: Task Priority: Major - P3
Reporter: Sergi Mateo Bellido Assignee: Antonio Fuschetto
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File LongCollectionNameSupport FSM.png    
Issue Links:
Depends
is depended on by SERVER-58571 shardCollection command should enable... Closed
is depended on by SERVER-58572 Extend the CatalogCache Loaders to pr... Closed
is depended on by SERVER-58573 Add a new configsvr command that mod... Closed
is depended on by SERVER-58574 Modify the setFCV command to set/unse... Closed
is depended on by SERVER-58575 Replace the logic that decides whethe... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding EMEA 2021-08-09
Participants:

 Description   

Add a new optional boolean field to config.collections and to config.cache.collections that represents whether a collection supports long names. As part of this work we should also expose methods to get/set this flag.

The interesting part of this task is to think about the compatibility with previous versions. What happens if I try to parse 5.0 metadata with a 5.1 binary? What does it mean if this field is not present? These are the type of questions we have to solve here. You can get some ideas from allowMigrations.



 Comments   
Comment by Vivian Ge (Inactive) [ 06/Oct/21 ]

Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you!

Comment by Githook User [ 06/Aug/21 ]

Author:

{'name': 'Antonio Fuschetto', 'email': 'antonio.fuschetto@mongodb.com', 'username': 'afuschetto'}

Message: SERVER-58570 Add a new field to config.collections/config.cache.collections representing whether a collection supports long names
Branch: master
https://github.com/mongodb/mongo/commit/400820d43452952cc12ae8690e3157840e7a51d2

Comment by Antonio Fuschetto [ 02/Aug/21 ]

Analysis

The requirement is to have a state (a variable) that represents the current configuration of the feature supporting the long collection names.

The actors involved in the story are:

  • Unpatched old branches that do not support the feature at all (i.e., from 4.0 up to 5.0).
    • The only possible configuration state is disabled.
  • Patched old branches that support the feature (i.e., from 4.0+ up to 5.0+).
    • The possible configuration states are disabled (default) or explicitly enabled (which means that the user explicitly has enabled the feature using a dedicated command).
  • 5.1 binary with FCV set to 5.0.
    • The possible configuration states are disabled or explicitly enabled.
  • 5.1 binary with FCV set to 5.1.
    • The possible configuration states are explicitly enabled and implicitly enabled (the feature was disabled, but setting FCV to 5.1 this has been implicitly enabled).

The following table summarizes the involved actors, possible configuration status and allowed transactions:

Supporting feature 5.0 Binary / 5.0 FCV 1 5.1 Binary / 5.0 FCV 5.1 Binary / 5.1 FCV
No Disabled (unavailable) Disabled Implicitly enabled
Yes Disabled (unavailable) Disabled Implicitly enabled
Yes Explicitly enabled Explicitly enabled Explicitly enabled

1 Or older versions.

The last two columns represent the allowed transactions for setting FCV from 5.0 to 5.1 and vice versa. This also highlights the need to have a three-state variable instead of a simpler binary state, i.e., downgrading from FCV 5.1 to 5.0 must know if the feature has been explicitly or implicitly enabled in order to disable or leave it enabled.

Solution

NOTE: The following is a speculative solution based on current knowledge of the problem and existing implementation.

A valid candidate as a variable name is LongCollectionNameSupport.

From a technical perspective, this can be implemented using an optional boolean where the possible values correspond to:

  • None: Disabled
  • False: Implicitly enabled
  • True: Explicitly enabled

Thus, the allows state transactions are:

Details

  • Why cannot opt for an enumeration variable directly? Because we need to cover use cases where the new 5.1 binary must work with 5.0 metadata and must allow the downgrade from FCV 5.1 to 5.0. In this scenario, an optional Boolean seems to me the most suitable solution.
Generated at Thu Feb 08 05:44:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.