Skip to content

Conversation

johnjackweir
Copy link
Collaborator

WRITING-33247 defines a new pattern of MongoDB owned internal DBs prefixed with __mdb_internal_

Here I propose hiding all special dbs as determined by the mongodb-ns package with the reasoning that users should generally not be aware of these internal DBs, nor should they make changes to them

As of right now, this does not stop a user from creating a new collection in these DBs

Description

Checklist

  • New tests and/or benchmarks are included
  • Documentation is changed or added
  • If this change updates the UI, screenshots/videos are added and a design review is requested
  • I have signed the MongoDB Contributor License Agreement (https://www.mongodb.com/legal/contributor-agreement)

Motivation and Context

  • Bugfix
  • New feature
  • Dependency update
  • Misc

Open Questions

Dependents

Types of changes

  • Backport Needed
  • Patch (non-breaking change which fixes an issue)
  • Minor (non-breaking change which adds functionality)
  • Major (fix or feature that would cause existing functionality to change)

@johnjackweir johnjackweir changed the title (chore)- hide system DBs COMPASS-9674 feat(database-model,database-collections,collection-model): hide system DBs COMPASS-9674 Sep 15, 2025
@github-actions github-actions bot added the feat label Sep 15, 2025
@johnjackweir johnjackweir changed the title feat(database-model,database-collections,collection-model): hide system DBs COMPASS-9674 feat(database-model,databases-collections,collection-model): hide system DBs COMPASS-9674 Sep 15, 2025
@johnjackweir
Copy link
Collaborator Author

I'll fix the tests but open to any initial feedback on this overall approach of hiding and disallowing additions to the"special" collections

@@ -379,6 +383,14 @@ export const createNamespace = (
dispatch(handleError(new Error(NO_DOT)));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I broke this flow ~2 years ago and we never noticed. This should return, otherwise we are continuing to create the namespace even if validation failed.

Suggested change
dispatch(handleError(new Error(NO_DOT)));
return dispatch(handleError(new Error(NO_DOT)));

Comment on lines 386 to 392
if (dbName && toNS(dbName).special) {
dispatch(handleError(new Error(INTERNAL_DATABASE)));
}

if (toNS(namespace).special) {
dispatch(handleError(new Error(INTERNAL_COLLECTION)));
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same wrt returns

Suggested change
if (dbName && toNS(dbName).special) {
dispatch(handleError(new Error(INTERNAL_DATABASE)));
}
if (toNS(namespace).special) {
dispatch(handleError(new Error(INTERNAL_COLLECTION)));
}
if (dbName && toNS(dbName).special) {
return dispatch(handleError(new Error(INTERNAL_DATABASE)));
}
if (toNS(namespace).special) {
return dispatch(handleError(new Error(INTERNAL_COLLECTION)));
}

Comment on lines +267 to +269
.filter((db) => {
return toNs(db.name).special === false;
})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the top of my head I think that should be an okay change, but I don't know enough about these special collections to say with confidence that we are not breaking some power user use-cases in Compass. Would it make sense to gate this with some new preference setting and allow people to opt-in?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants