[SERVER-31576] Allow users to easily query for the list of Views in their database Created: 16/Oct/17 Updated: 27/Oct/23 Resolved: 16/Oct/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Cailin Nelson | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | read-only-views | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Currently, it is a little bit tricky to determine the list of views in a database. There are two options:
The first option is both tedious (grant needs to be performed for the system.views collection on every database) and also probably not something we really want users to rely on. (See The second is a little obscure. It does not seem reasonable to assume that an external user can piece together that a view is a collection without a storageEngine. Suggestion: add a new field to each entry in the output of listCollections that indicates whether or not the entry represents a collection or a view, and add a new option for the supported filters on the listCollections command so that a list of only-views can be returned. |
| Comments |
| Comment by Cailin Nelson [ 16/Oct/17 ] | |
|
Ah, excellent. That filter option is not listed in the documentation so I did not know it existed. I'll pass this along to the Atlas user that requested this functionality. | |
| Comment by Max Hirschhorn [ 16/Oct/17 ] | |
|
cailin.nelson, the response from the "listCollections" command includes a type="view" element for any entries from the "system.views" collection. It is also possible to filter on the type field to return only the views.
Is there a different reason you were depending on the options.storageEngine field? The options.storageEngine field should only be present in the response from the "listCollections" command for collections that explicitly specified the storageEngine field to the "create" command. |