[SERVER-54852] Break up CollectionOptions into one struct for accepting user options and another for persisting to the catalog Created: 01/Mar/21 Updated: 06/Dec/22 Resolved: 12/Sep/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Louis Williams | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Storage Execution
|
| Participants: |
| Description |
|
The CollectionOptions struct is a mixture of some user-provided options that are serialized and persisted directly to the durable catalog (i.e. capped) and others that are user-provided but and dispatched into other actions (i.e. timeseries), but never directly serialized. This multipurpose struct accepts a ParseKind flag that validates options based on whether the struct is being used for storage or user options. It would make sense to have one structure for holding all user-provided options and another that is used only to serialize/deserialize to the catalog. |