[SERVER-42629] Duplicate 'ns' field in the DurableCatalog Created: 05/Aug/19  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Catalog, Storage
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Gregory Wlodarek Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-41696 Stop generating the 'ns' field for in... Closed
related to SERVER-41746 Test varying lengths of collection names Closed
Assigned Teams:
Storage Execution
Participants:

 Description   

While working on SERVER-41746 I noticed that it was impossible to insert collection names with a length of >= ~8MB. When a new entry is added into the DurableCatalog, we append the 'ns' field twice here.

{
    ns: <String>,
    ...
    md: {
        ns: <String>,
        ...
    },
    ...
}

With a collection name that is <= ~8MB, that quickly brings us up to our 16MB BSON document limit.
Removing one of these fields would lower the cost of having to maintain both the fields whenever a namespace change occurred and allows the insertion of even longer collection names.



 Comments   
Comment by Gregory Wlodarek [ 06/Aug/19 ]

After discussing with geert.bosch, the md.ns field should be the easier of the two to remove. We'll need to keep backward compatibility in mind when removing the field as prior server versions depend on both fields. Doing some work for 4.2.1+ we could make it so that it uses the top-level ns field only and ignores the md.ns field. We would still have to update both fields upon any updates though. This would allow us to remove the md.ns field entirely for 4.4.

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