Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
feat: add getViews and categorize table types #3327
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 5.x
Are you sure you want to change the base?
feat: add getViews and categorize table types #3327
Changes from 8 commits
c32dd99
196405b
3162280
ae5187a
12b6d1f
825a4fe
19f1cdd
7a774e9
44a57f5
ef91b44
4890eca
0e14a68
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The system collections are actual collections. In the case of
system.profile
, that might actually be something an application would want to query.I'm not certain it makes sense to exclude these from all output through the integration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is relevant, the information can be provided via
$collStats
(MongoDB 6.2+). I'm not sure that'd be worth the overhead to obtain this for all collections/views, though.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is actually relevant, the information should be available via the
options
field for each collection info result. See:listCollections
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will preserve system collection from being dropped 👍🏻
Even for the gridfs bucket metadata, I think that's good to not remove this collection when
dropAllTables
is called.https://www.mongodb.com/docs/manual/reference/system-collections/#database-specific-collections
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
system.buckets
stores data for time series collections. It's unrelated to GridFS, which stores its data in<bucketName>.fs
(metadata) and<bucketName.files>
(chunk data) collections.I'm not sure how
dropAllTables()
is used, but I don't see why you'd need system collections to persist if everything else is being removed. Moreover, ifBlueprint::drop()
(called bydropAllTables()
) is going to invokeCollection::drop()
for each collection, you could conceivably just drop the entire database to be more efficient.