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.

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.

Deleting tens of millions of documents can have a big impact on the performance of the Clusters, even using Bulk Delete. A "Limit" must be added to Delete and Bulk Delete to let us limit the number of operations, making sure we do not kill the Clusters' performance.

• For the delete, this would make sure we only delete n number of documents.
• For the Bulk Delete, this would also make sure we only delete n number of documents, or it could instead limit the number of batches/groups of documents to be deleted.

Right now, the only solution is a hack, which is to query the documents with a Limit and a projection to get the IDs, then delete only those. This means we need to do large queries/projections and large delete operations. This workaround/hack is not efficient and not good in any possible way. It is, after all, just a temporary hack we have to use until a valid solution is supported by MongoDB, which is to add a Limit to deletes.

The storage watchdog attempts to create, write, and read a test file in critical directories every 10 seconds.

The watchdogPeriodSeconds parameter controls how often these a thread checks to ensure at least one check has succeeded since the last check.

The minimum value for watchdogPeriodSeconds is 60 seconds. This means that in the worst case, the mongod could be unable to write for up to 2 minutes before the watchdog asserts and kills the stalled node. That is a very long time for a primary node to be stalled in a busy cluster.

It does make sense that watchdogPeriodSeconds must be greater than the check frequency. However, reducing the minimum from 60 seconds to 20 or 30 seconds would still permit multiple check cycles per period, but would significantly reduce the maximum length of time that the node could be stalled.

When performing a bulk operation, it is possible to obtain the _ids of upserted documents via BulkWriteResult. For example:

db.getCollection("test").find({})

db.test.drop()

var bulk = db.test.initializeUnorderedBulkOp();
bulk.find({name: "huey"}).upsert().updateOne({name: "huey"});
bulk.execute();
```

The BulkWriteResult contains the upserted _id:

BulkWriteResult({
"writeErrors" : [ ],
"writeConcernErrors" : [ ],
"nInserted" : 0,
"nUpserted" : 1,
"nMatched" : 0,
"nModified" : 0,
"nRemoved" : 0,
"upserted" : [
{
"index" : 0,
"_id" : ObjectId("5ec77b5cc4a955ce03a4cd2e")
}
]
})

However, when a document already exist, the _id is not returned:

db.test.find()

var bulk = db.test.initializeUnorderedBulkOp();
bulk.find({name: "huey"}).upsert().updateOne({name: "huey", outfit: "red"});
bulk.find({name: "luey"}).upsert().updateOne({name: "luey", outfit: "green"});
bulk.find({name: "duey"}).upsert().updateOne({name: "duey", outfit: "blue"});
bulk.execute();

Returns:

BulkWriteResult({
"writeErrors" : [ ],
"writeConcernErrors" : [ ],
"nInserted" : 0,
"nUpserted" : 2,
"nMatched" : 1,
"nModified" : 1,
"nRemoved" : 0,
"upserted" : [
{
"index" : 1,
"id" : ObjectId("5ec77b5cc4a955ce03a4cd39")
},
{
"index" : 2,
"id" : ObjectId("5ec77b5cc4a955ce03a4cd3a")
}
]
})

This forces you to make a subsequent query to retrieve the entries that weren't upserted.

This request is that BulkWriteResult incorporates a list of matched document ids on a bulk upsertOne operation when it turns out that the documents already exist