[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: |
|
||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||
| 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: | ||||||||||||||||
| Comment by Antonio Fuschetto [ 02/Aug/21 ] | ||||||||||||||||
AnalysisThe 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:
The following table summarizes the involved actors, possible configuration status and allowed transactions:
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. SolutionNOTE: 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:
Thus, the allows state transactions are: Details
|