[SERVER-29926] system.indexes collection should have a UUID when UUIDs are enabled and featureCompatibilityVersion is 3.6 Created: 29/Jun/17 Updated: 06/Dec/22 Resolved: 05/Oct/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | MMAPv1 |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Maria van Keulen | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
When I do db.getCollectionInfos() on admin and local, I notice system.indexes appears in the output with no UUID set while other collections in these databases do. |
| Comments |
| Comment by Andy Schwerin [ 05/Jul/17 ] |
|
Makes sense. Acknowledged. |
| Comment by Geert Bosch [ 30/Jun/17 ] |
|
Yes, on MMAPV1 there is a Collection object for it, as there is for system.namespaces. When doing a listCollections you see this in the output, you can query against them etc. In particular, i'd like to be able to have the invariant that all Collection objects in 3.6 and on have UUIDs, so we can change OptionalCollectionUUID to CollectionUUID, lock collections by UUID rather than name, etc. I'm afraid that if we have two holdout collections on MMAPv1 without UUID that that is going to be a source of trouble. As we'll have MMAPv1 around until 4.0, and changing it to no longer expose system.namespaces and system.indexes as collections is unlikely to be acceptable, I think the easiest choice is to just give system.indexes a UUID, and make up an ephemeral one for each system.namespaces collection. |
| Comment by Andy Schwerin [ 30/Jun/17 ] |
|
Is this really an error? Is system.indexes even a real collection? |