OPERATIONAL DEFECT DATABASE
...
...
BugZero found this defect 2629 days ago.
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.
schwerin commented on Wed, 5 Jul 2017 14:22:09 +0000: Makes sense. Acknowledged. geert.bosch commented on Fri, 30 Jun 2017 02:00:10 +0000: 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. schwerin commented on Fri, 30 Jun 2017 00:49:43 +0000: Is this really an error? Is system.indexes even a real collection?
