Provide MongoDB customers/users with an understandable release notes, especially for bugfixes.
What are the risks this bugfix release covers, what is its urgency.

Right now, release notes are made of MongoDB Jira tickets, which are very detailed and refer to the implementation of MongoDB, and thus cannot be easily understood by end users.

As a suggestion, release notes could sum up the following data in a simple table:
- Nature of impact
-> data corruption: yes/no
-> downtime: of a single node / of the whole cluster / on a subset of requests / etc
- Context of impact
-> conditions: any sharded cluster / any cluster / only with SSL / only with multi-doc transactions / etc
-> trigger: spontaneous / on upgrade / on specific action / etc
- Workarounds
-> preemptive workaround: yes / no
-> corrective workaround: yes / no

This is a general idea, applicable for Mongo Database but also any other Mongo product.

This is an important matter to us, because it would guide us on when to allocate resources to install a bugfix update...and possibly avoid production failures (as we've had last month)

I would like MongoDB to add better support for ordered lists across documents in a collection. This feature would allow the user to designate a field such as "position", and the DB would ensure the values of that field across documents remain in a monotonically-increasing integer sequence 0, 1, 2, 3, ... N.

I am the maintainer of a Ruby library called "Mongoid Orderable". This library makes numerically ordered field across documents. I'd like to ask MongoDB to investigate moving the functionality of this library to the server.

What use case would this feature/improvement enable?

This feature would be useful in a wide-variety of real world applications; ordered lists are extremely common. In my app (standard SaaS related to restaurant management) I have at least 20 instances of such ordered lists.

Suggested implementation

I propose to do this using a new "ordered" index type.

For example, suppose my application has many Car documents, and I want to maintain the "position" of the Cars in a consistent order for each Dealer.

I add the following index to the Car collection:

Cars -> createIndex({ dealer_id: 1, position: 1 }, { ordered: 1 })

Then in my Car collection, I see:

Car A -> dealerid: ***, position: 0
Car B -> dealerid: **, position: 1
Car C -> dealer_id: **, position: 2
Car D -> dealerid: yyy, position: 0
Car E -> dealerid: yyy, position: 1

Due to this special "ordered" index, the position field will always maintain a zero-based ordered value for the given scope. If I modify any member, this ordering is preserved:

Change Car C position

Car C -> updateOne(position: 1)

Car A -> dealerid: ***, position: 0
Car B -> dealerid: **, position: 2 <-- updated
Car C -> dealer_id: **, position: 1 <-- updated
Car D -> dealerid: yyy, position: 0
Car E -> dealerid: yyy, position: 1

Change Car C dealer_id

Car C -> updateOne(dealer_id: yyy)

Car A -> dealerid: ***, position: 0
Car B -> dealerid: ***, position: 1 <-- updated
Car C -> dealerid: yyy, position: 1 <-- updated
Car D -> dealerid: yyy, position: 0
Car E -> dealer_id: yyy, position: 2 <-- updated

Change Car C position to be a very large value

Car C -> updateOne(position: 999)

Car A -> dealerid: ***, position: 0
Car B -> dealerid: ***, position: 1
Car C -> dealerid: yyy, position: 2 <-- updated, stays in order
Car D -> dealerid: yyy, position: 0
Car E -> dealer_id: yyy, position: 1 <-- updated

Change Car C position to a non-numeric value

Car C -> updateOne(position: "foo")

update is ignored; nothing changes

This feature should work with partial filter expressions, etc.

Currently with change streams it is impossible to know who or what connection initiated the changes.

It would be a good feature to have to be able to receive some data about the source client connection that initiated a change.

My particular use case is the following:

I have an app that connects to Atlas. (source client connection)
I can subscribe to change streams and then execute some logic when it applies.

That app can scale to multiple instances.
Each instance subscribes to the change streams.
But I only want each instance to execute the logic that applies to only events that they have initiated through their own connection.

Right now it seems impossible and the only way to do so would be to generate a unique App ID for each instance and log it in a separate collection for each change and subscribe to that. Although this would work, it would be simpler to have this feature built-in without the need for a separate collection.

Maybe this could be good for other use cases.

Another use case that I can think of, is the following:

If a change is done in a collection that is not made by the source client connection, then apply some logic.

For example: my app instance would execute some logic when data was manipulated outside my app, either manually or by third parties.

Hope I am being clear, thanks!

I want to be able to have a maintain array of counters for a user through a single update statement. If the document containing array of counters does not exist, I want to add it. If it does exist, I want to increment the counter

For example, this command

db.inboxItemCounts.updateOne(
// filter
{
"userId": userDoc.userId
},
// update
{
"$setOnInsert": {
"userId": userDoc.userId,
"fromUserSummary": [{
"userName": fromUserDoc.userName,
"count": 1
}]
},
// "$inc": incBody,
"$inc": {
"fromUserSummary.$[userElement].count": 1
}
},
// options
{
"upsert": true,
"writeConcern": { "w": "majority" },
"arrayFilters": [
{ "userElement.userName": { $eq: fromUserDoc.userName }}
]
}
);


produces this error
"MongoServerError: Updating the path 'fromUserSummary.$[userElement].count' would create a conflict at 'fromUserSummary"

That's ridiculous because the command knows that what's is to be used on insert versus update.

The $densify aggregation pipeline stage seems unable to evaluate range bounds expressions, requiring the range bounds to be constant.

See the following example (the collection testcoll contains a single documents with only the _id field):

sometestdb> db.testcoll.aggregate([{$addFields: {a: 1}}, {$densify: {field: "a", range: {bounds: [0, 5], step: 1}}}])

[

  { a: 0 },

  { _id: ObjectId("6284a16d64553eaf74b1e189"), a: 1 },

  { a: 2 },

  { a: 3 },

  { a: 4 }

]



sometestdb> db.testcoll.aggregate([{$addFields: {a: 1}}, {$densify: {field: "a", range: {bounds: [{$toInt: "0"}, 5], step: 1}}}])

MongoServerError: A bounding array must be an ascending array of either two dates or two numbers

The first aggregate() call gives the correct result, and I'd expect the second one to evaluate the $toInt and yield the same result. Of course $toInt isn't a particularly useful use case but there are indeed useful computations which an user may want to do on the range bounds; for example, when using dates, one may want to truncate the start and end date to the hour or to the day before they are used for the densify operation.

We recently had an issue where an index did not get created on all shards. When we ran getIndexes() on mongos it reported the index was present. So we dropped another redundant index thinking all would be well - it was not. We had serious performance issues on the shard that was missing the new index and our app was unavailable for a few hours whilst we re-created the missing index on a huge collection.

It would be better if getIndexes called on mongos reported some sort of warning or indication that it was not present on all shards. The same should also be clear on mongo cloud's index view. Even better would be some guarantees that an index will get distributed to all shards, even if there is a transient problem with one of the shards.