Currently, there is no way for Database Users to manage their own passwords, (even if they are atlasAdmin@admin). Moreover, as a Project Owner, I cannot create a role that allows them to do so, e.g.:

use admin

db.createRole(

   { role: "changeOwnPasswordRole",

     privileges: [

        {

          resource: { db: "", collection: ""},

          actions: [ "changeOwnPassword"]

        }

     ],

     roles: []

   }

)

As such, changing passwords always requires a Project Owner setting the new password and sharing it with the Database User. This is a problem, because user-password combinations known by more than one person do not serve as proof of identity.

A Database User should, either by default or via a role, have the changeOwnPassword Mongo permission, so they can change their own passwords without having to share them with someone else (i.e. a Project Owner).

Often Views, defined by an aggregation pipeline, are used to filter out certain fields, certain records and obfuscate parts of certain values to enable users with a specific restricted role to only see a subset of 'less sensitive' data from a collection. Views can be assigned to a role declaratively, but in some use cases it is also useful to allow the aggregation pipeline logic to be able to access the context of the current session's roles (e.g. $$ROLES) or user id (e.g. $$USER) to be able to make some programmatic decisions of what to show in the view based on current user & role (i.e. to perform programmatic role based access control).

In some examples, this aggregation pipeline may even want to use $$ROLES or $$USER to then perform a $lookup on a different 'metadata' collection, to influence what it decides to return as the output of the view.

Currently if you perform a find or other operation, and you have a typo in your collection name, the operation will execute successfully and there is no indication that the collection you are operating on doesn't exist. It would be handy if there were some sort of session variable that could be set that tells the engine, to return an error if the collection being operated on does not exist. For example, lets say we have a collection named "myCollection". If I issue a find with a typo in the collection name from the shell like:

db.myCollectio.find();

This will successfully run and return no records even though "myCollectio" doesn't
exist. If there were some way to say, I want to enforce and check that the collection actually exists as part of the collection operation such that if the above command were issues, and error would be thrownindicating "myCollectio" does not exist.

This would save a lot of troubleshooting headaches in that people don't always realize there is a typo in their collection name.

I'm not sure if this would be a database engine modification or a shell modification.

MongoDb only allow one text index by collection, in contrast of other index types.

This is a limitation that makes it difficult to develop projects with search functionality, for example, if you want to add a text search for advanced users on all fields and a public search on a subset of fields, there isn't a simple and performant way to solve it.

Many developers end up using other products like elastic search, or creating additional collections and using lookup, or using preg_reg or building smart indexes when the creation of multiple text indexes per collection would allow a quick, easy, and efficient solution for many of these scenarios.
 
This would be a good feature for mongodb :)

In this old thread from 2016 (https://groups.google.com/forum/#!topic/mongodb-user/LCeFZZRz5EY) it was asked whether there was a way to increase the 100mb in memory limit of each stage of an aggregation pipeline. The responses centered around two points:

1. If too much memory is used per aggregation pipeline stage then it will reduce performance for the overall MongoDB database, impacting other queries negatively.


2. You can set allowDiskUse: true and revert to performing these pipeline stages on disk when they exceed 100mb.

I believe this subject needs to be revisited for the following reasons:

1. “Too much memory” is very subjective, and the 100mb number is arbitrary. The hardware for a typical MongoDB database setup in 2016 is not the same as in 2020. And what is the MongoDB use case for one company isn’t the use case for another company. Company A might have top of the line hardware they are running MongoDB on and only have a few concurrent users, and need large in memory aggregation queries to run fast so want to set a limit of 200mb or even higher. Company B might have lesser hardware and many concurrent users, and want to set the limit to 50mb or less.


2. The allowDiskUse: true option is nice to have, but it obviously comes at a huge performance hit once your aggregation pipeline stages exceed the 100mb limit, even on high performance SSD drives.

This really comes down to who knows best what the limit should be, the company’s developers and database / server ops teams or the MongoDB developers? The MongoDB developers obviously have much more knowledge on the inner workings of Mongo, but that advice can still be taken into account by having a default limit of 100mb. I believe very strongly that today in 2020 this limit should be configurable so that we can customize the behavior for our own specific situation. The documentation can of course provide a warning that changing the setting can impact performance (although everyone already knows that.)

If you want to get into the details of why my company needs to increase this limit, and why it has been holding us back from switching from SQL Server to MongoDB for the last year (despite spending 6 months developing a working Mongo solution) then we can get into specifics. But really that will distract away from the central issue, which is that different customers have different scenarios, and a “one size fits all” solution isn’t appropriate and needs to be customizable.