8 results found

1. Support CentOS 8 alternatives like AlmaLinux or RockyLinux

   As we all know, CentOS 8 has its EOL by December 2021. So it would be highly appreciated when the possible alternatives like AlmaLinux and/or RockyLinux would be officially supported

   78 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   19 comments  ·  Delete…  ·  Admin →
   completed  ·  AdminAlex Ettouati (Admin, MongoDB) responded

   Happy to share that MongoDB now officially supports Rocky Linux and AlmaLinux. Check out the blog post for more information.

2. Allow views with programmatic role based access control rather than just declarative

   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.

   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… more

   15 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   3 comments  ·  Delete…  ·  Admin →
   completed  ·  AdminKatya (Product Manager, Query, MongoDB) responded

   MongoDB 7.0 provides variable USER_ROLES that can be used in the view definition pipeline!

   Link to documentation

3. Support throttling the balancer for sharded clusters

   As high throughput clusters grow and documents become larger, the MongoDB balancer may begin impacting workloads.

   I'd like the ability to throttle the speed at which the balancer or chunk migrator runs such that impact is minimised.

   6 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Sharding  ·  Delete…  ·  Admin →
   completed  ·  AdminMatt (Product Manager, Sharding, MongoDB) responded

   New in version 7.0 and also available in 6.3.1, 6.0.6, and 5.0.18 is the balancerMigrationsThrottlingMs server parameter. This new parameter allows you to specify the minimum amount of time between balancing rounds which ultimately affects the balancing rate.

4. provide detailed description why schema validation failed

   currently if document failed to pass schema validation, there is no information WHY it's failed. if you have complex/lengthy schema validation, it's pretty hard to figure out what exactly the issue (for example, field may simple have different low/upper case, single/plural form, data type etc...

   if mongo returns detailed error stack - it would simplify troubleshooting

   5 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   completed  ·  2 comments  ·  Delete…  ·  Admin →

5. Supporting hashed fields in compound indexes and shard keys

   Hello,

   We have been using hashed keys to shard in regular clusters, they are useful for pre-sharding and keeping a balanced cluster without having to rely on the balancer.

   Global clusters and zone sharded clusters, we must use a compound shard key to identify both the zone and the shard key.

   MongoDB does not currently support compound shard keys containing hashed fields, making it cumbersome for us to use zone sharding.

   MongoDB could be improved by supporting hashed fields in compound keys.

   5 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   completed  ·  AdminKatya (Product Manager, Query, MongoDB) responded

   Released in 4.4 https://docs.mongodb.com/manual/release-notes/4.4/index.html#compound-hashed-shard-keys

6. Internal-node lookup for Sharded Collections

   We have a system with "Write First" strategy for multiple collections which we need to Shard.
   We also need to run lookups command on those collections, sometimes from a collection to itself and sometimes from one Sharded collections to another Sharded collection.
   For those collections we have the same Shard-Keys and the lookup operation will always contain the shard key as the lookup field (or part of it).
   We need the ability to allow Internal-node lookup operations for those Sharded collection - a new command or a flag to the existing lookup command for allowing lookup on a Sharded collection but only in the same node where the "from" document resides.

   We also need the ability to control the Sharding distribution of two or more collections with the same Shard-keys, to force those collections to be Sharded together so that documents from those different collections with the same Shard-key will be saved / managed in the exact same nodes.
   By forcing this Sharding strategy we will be able to use the new "Internal-node" lookup command also for multiple collections.

   We have a system with "Write First" strategy for multiple collections which we need to Shard.
   We also need to run lookups command on those collections, sometimes from a collection to itself and sometimes from one Sharded collections to another Sharded collection.
   For those collections we have the same Shard-Keys and the lookup operation will always contain the shard key as the lookup field (or part of it).
   We need the ability to allow Internal-node lookup operations for those Sharded collection - a new command or a flag to the existing lookup command for allowing lookup on a Sharded collection… more

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Sharding  ·  Delete…  ·  Admin →
   completed  ·  AdminKatya (Product Manager, Query, MongoDB) responded

   Support for sharded collections in $lookup and $graphLookup was released in MongoDB 5.1.
   Please check it out.
   https://docs.mongodb.com/upcoming/release-notes/5.1/#aggregation

7. Add $sort as an array operator in the agg framework

   $filter and $map and $reduce allowed us to stop using $unwind all the time. I know $sort is likely the most computationally expensive peer function to $filter and $map but there are so many times that I have a field with an array of things (scalars or objects) and I need either the whole array in a sorted order or the first or last thing in the sort, for which I would use $arrayElemAt:[ {$sort: {input: ... }}, 0 ] . I see the $sort function signature looking almost like $filter:
   {$sort: {input: <expr that evals to array>,
   as: "gg" , // name of local list,
   fields: [ {"$$gg.fld1":1}, {"$$gg.fld2":-1}, ... ]
   }

   $filter and $map and $reduce allowed us to stop using $unwind all the time. I know $sort is likely the most computationally expensive peer function to $filter and $map but there are so many times that I have a field with an array of things (scalars or objects) and I need either the whole array in a sorted order or the first or last thing in the sort, for which I would use $arrayElemAt:[ {$sort: {input: ... }}, 0 ] . I see the $sort function signature looking almost like $filter:
   {$sort: {input: <expr that evals to array>,
   as: "gg"… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Query and Aggregation Pipeline  ·  Delete…  ·  Admin →
   completed  ·  AdminKatya (Product Manager, Query, MongoDB) responded

   feel tree to add comments if $sortArray doesn't meet your expectations

8. Old and New values in change tracking

   Change streams currently return only the new version of the documents.

   If there were an option that could be set on the collection for the change streams to also return the old version of the document, it would simplify any business logic that requires the old version.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Change Streams  ·  Delete…  ·  Admin →
   completed  ·  AdminKatya (Product Manager, Query, MongoDB) responded

   Ability to capture pre-image of the document before change and include both pre- and post-image was released in  MongoDB 6.0.

   https://www.mongodb.com/docs/manual/release-notes/6.0/#change-streams-with-document-pre--and-post-images