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.

Disclaimer: I'm aware that this is a pretty big feature request.

Currently a document has a max size of 16 mb. I'm not suggesting changing that. However, I'm suggesting changing how that size is calculated.

I'm designing a database in which documents have a tree structure. The document will have an array called "nodes", which can hold any number of child nodes. Those nodes can also have arrays of nodes, and so on. It's a simple tree structure.

For major users of my application, that outer document could get pretty big. It's not a problem right now (no users, no problems) but if my app goes big time I'd have to do a major overhaul to how I structure those hierarchies. Yes, I could design it like that from the get go, but the hierarchical structure is so easy and simple that, for now, I'm going with it.

Now, here's what I'm proposing:

Instead of internally storing each hash as a structure within a document or within another hash, store it as a reference to that hash. To the programmer it would look the same. However, the size of the document would only be based on the sizes of the references to the hashes, not the size of the hashes themselves. So the document, and its nested hashes, does not contain all the nested hashes, but only the their references. The document could be effectively much bigger because references don't take up much space.

I throw the topic out for discussion.

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.

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!

When upgrading the MongoDB server community edition from a very old version to the newest version one cannot skip installing intermediate versions, e. g. version 3.6 -> 4.4 does not work because the database files cannot be auto-migrated and the FeatureCompatibilityVersion is too low on 3.6 (or not existent).

Instead we have to install 3.6 -> 4.0 -> 4.2 -> 4.4 and execute db.adminCommand( { setFeatureCompatibilityVersion: "..." } ) appropriately in between installing each new version.

I propose creating an additional installer package for Linux which takes care of all that to migrate the internal database structure from the installed version to the latest but recent version available to apt - including setting FeatureCompatibilityVersion. This "upgrade-package" would contain all files necessary to upgrade from 3.6 -> 4.2 (in my example) so that the upgrade from 3.6 to 4.4 would not fail.