272 results found

1. Add option to $dayOfWeek to choose between Monday and Sunday

   Hi!

   I was wondering if you could add an optional parameter to $dayOfWeek that allows you to choose on which day you want the functionality to start counting.

   Thanks!

   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 →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Multi-version-intermediate upgrade package

   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.

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

   0 comments  ·  Administration  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Add regex support in pipeline operator `replaceAll`

   It would be very nice to have something like this possible:

   { $replaceAll:
      { input: "$text", find: "/[;,.]/g", replacement: "." }
   }
   

   Many thanks !

   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  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Have an API to have the History of Primary Nodes

   Have an API to have the History of Primary Nodes,from the time the Replica set is initiated.I know we can have alerts for Primary switch over,but if we want to analyse the data of elections/primary node for say about last 1 year , an API would help.

   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

   0 comments  ·  Administration  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Support mongos + ops manager agents as a container sidecar
   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

   0 comments  ·  Workload Management  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Please create a build in role that grants developers all permissions needed to add/edit schema validations short of adminAll.

   Please create a built-in role that grants developers all permissions needed to add/edit schema validations short of dbAdminAnyDatabase.

   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

   0 comments  ·  Security  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. x509 authentication with other certificate's components than (O,OU,DC)

   In some entities (e.g. ours), the O, OU, DC triplet is not detailled enough or not appropriate, which makes it impossible to authenticate through x509.

   For exemple, in our entity, the O and OU are the same for all certificates (because all servers are in the same Organisation Unit), and the DC field is not used. We do use other fields though.
   Because of that, we can't use the x509 authentication feature, although it is strongly asked for by the security Team.

   Would it be possible to enhance the x509 authentication mechanism to allow more flexibility for the authentication's fields?

   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  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. URL Decode `readPreferenceTags`

   If a url encoded value is set to readPreferenceTags it will be ignored causing for instance connecting to analytics node impossible from tooling that correctly encodes the urls.

   It can look like this for instance: readPreferenceTags=nodeType:ANALYTICS becomes readPreferenceTags=nodeType%3AANALYTICS

   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

   0 comments  ·  Replication  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. Provide straightforward syntax for 1-to-1 joins in aggregation

   The syntax for joins that bring back multiple documents from foreign collections is very straightforward and yields exactly what one would expect, but simple joins that are bread and butter in SQL require very convoluted and expensive to run syntax.

   Consider a product database that has products, categories and reviews collections. Each product has a unique category and may have multiple reviews. Getting all reviews in an aggregation is very straightforward (top stage), but getting categories, similar to SQL, is as convoluted as it gets (bottom stage).

   db.products.aggregate(
   [
       //
       // Document aggregates naturally aggregate foreign documents
       // into the primary document.
       //
       {$lookup: {
         from: "reviews",
         localField: "_id",
         foreignField: "product_id",
         as: "reviews"
       }},
   
       //
       // A simple join that is supposed to bring a couple of fields
       // into the primary document translates into this convoluted
       // syntax just to get those two fields.
       //
       {$lookup: {
         from: "categories",
         let: {category_id: "$category"},
         pipeline: [
           {$match: {
               $expr: {$eq: ["$_id", "$$category_id"]}
           }},
           {$project: {
               _id: 0,
               cat_name: "$category",
               cat_description: "$description"
           }}
         ],
         as: "category_details"
       }},
       {$replaceRoot: {
         newRoot: {
           $mergeObjects: [
             "$$ROOT", {$arrayElemAt: ["$category_details", 0]}
           ]
         }
       }},
       {$project: {
           category_details: 0
       }}
   ])
   

   Notice that keeping category.category and category.description in products, the noSQL-way, isn't an option because updating 10000's of products when category or description change is just not a good idea any way one looks at it. Denormalization is useful in many noSQL scenarios, but this isn't one of them.

   Having some simple join syntax that would identify the joined collection as a 1-to-1 join and would bring field names and values as if they existed in the primary document, possibly aliased via a projection-like syntax, would be extremely helpful in keeping aggregations readable, keeping data reasonably normalized, and would run much faster because it would be just multiple parallel BSON append calls when constructing aggregation results documents.

   Data for the query:

   products:
   
{"_id":{"$oid":"6140e6c6dfe7b9d6e597d07e"},"name":"Product A","category":1,"price":111}
{"_id":{"$oid":"6140e6c6dfe7b9d6e597d07f"},"name":"Product B","category":2,"price":222}
{"_id":{"$oid":"6140e6c6dfe7b9d6e597d080"},"name":"Product C","category":1,"price":333}

   categories:
   
{"_id":1,"category":"Clothing","description":"All kinds of clothing"}
{"_id":2,"category":"Electronics","description":"Cool gadgets"}

   reviews:
   
{"_id":{"$oid":"6140e7cadfe7b9d6e597d08a"},"product_id":{"$oid":"6140e6c6dfe7b9d6e597d07e"},"review":"Product A is great","rating":4}
{"_id":{"$oid":"6140e813dfe7b9d6e597d090"},"product_id":{"$oid":"6140e6c6dfe7b9d6e597d07f"},"review":"This product is horrible","rating":1}
{"_id":{"$oid":"6140e8eff4ff76778b48ba88"},"product_id":{"$oid":"6140e6c6dfe7b9d6e597d07f"},"review":"This product is not the best, but usable","rating":2}


   The syntax for joins that bring back multiple documents from foreign collections is very straightforward and yields exactly what one would expect, but simple joins that are bread and butter in SQL require very convoluted and expensive to run syntax.

   Consider a product database that has products, categories and reviews collections. Each product has a unique category and may have multiple reviews. Getting all reviews in an aggregation is very straightforward (top stage), but getting categories, similar to SQL, is as convoluted as it gets (bottom stage).

   db.products.aggregate(
   [
       //
       // Document aggregates naturally aggregate foreign documents
       // into

   … 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

   3 comments  ·  Query and Aggregation Pipeline  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. Data Replication from one MongoDB Cluster to another MongoDB Cluster

    Create an option for the user to replicate data from one MongoDB Cluster to another MongoDB Cluster inside the account. We don't need to migrate data, I need replicate data from an Production Cluster to an Dev/Test Cluster. Thanks.

    8 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  ·  Replication  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. geoContain

    Dear all,
    according to the attached image, I have some documents (in blue, with id from 1 to 5) having a geographic extent and a search area (in yellow).
    I need to find all documents where search area is completly inside the document's geometry.
    Using different words, I need to find all documents where geometry completly covers the given search area.
    In my sample, the geo query should return the document with id 1.
    This kind of query has a opposite logic than the $geoWithin

    Could you provide a $geoContain functionality in the next future?

    •  

    10 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  ·  Query and Aggregation Pipeline  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

12. support $lookup for update aggregation

    We frequently denormalise either full documents or subsets to different documents in order to speed up reading, create indexes or paginate/sort on fields.

    Consider a user collection and a task collection, if a task can be assigned to the user, it makes sense to just put the user document on the task they are assigned. But an update to a user now requires you to update the user both in the user collection and all tasks with that user in the tasks collection.

    This can be achieved but does introduce some complexity, however the introduction of updates using aggregation pipelines could eliminate this problem if they supported the $lookup operator.

    So we could achieve the desired result using two simple operations

    db.collection('users').updateOne({id: '1234'}, {$set: ...})
    db.collection('tasks').updateMany({"user.id": '1234'}, [
    {
    $lookup: {
    from: 'users',
    localField: 'user.id',
    foreignField: 'id',
    as: 'user'
    }
    }
    ]);

    This would make it really simple to synchronise data between documents in different collections

    We frequently denormalise either full documents or subsets to different documents in order to speed up reading, create indexes or paginate/sort on fields.

    Consider a user collection and a task collection, if a task can be assigned to the user, it makes sense to just put the user document on the task they are assigned. But an update to a user now requires you to update the user both in the user collection and all tasks with that user in the tasks collection.

    This can be achieved but does introduce some complexity, however the introduction of updates using aggregation pipelines… more

    2 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

    2 comments  ·  Query and Aggregation Pipeline  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. the profile output in association with the $comment query operator need to have consistency across operations.

    I have observed the different profile result with regard to $comment query operator in association with find and update operation respectively as follows;

    • find operation shows a comment on the command.filter.$comment and the command.comment field in the system.profile collection.

      op: 'query',
      ns: 'db101.Bets',
      command: {
      find: 'Bets',
      filter: {
      _id: ObjectId("61a9db4b3bd34e4f68fb9abc"),
      '$comment': 'test-dba'
      },
      comment: 'test-dba',
      lsid: { id: UUID("43ebee67-3184-4ede-9cee-ecca7457861a") },
      '$db': 'db101'
      },

    • update operation shows a comment only on the command.q.$comment field in the system.profile collection.

      op: 'update',
      ns: 'db101.Bets',
      command: {
      q: {
      _id: ObjectId("61a9db4b3bd34e4f68fb9abc"),
      '$comment': 'test-dba'
      },
      u: { '$set': { odds: 0.5 } },
      multi: false,
      upsert: false
      },

    I have observed the different profile result with regard to $comment query operator in association with find and update operation respectively as follows;

    • find operation shows a comment on the command.filter.$comment and the command.comment field in the system.profile collection.

      op: 'query',
      ns: 'db101.Bets',
      command: {
      find: 'Bets',
      filter: {
      _id: ObjectId("61a9db4b3bd34e4f68fb9abc"),
      '$comment': 'test-dba'
      },
      comment: 'test-dba',
      lsid: { id: UUID("43ebee67-3184-4ede-9cee-ecca7457861a") },
      '$db': 'db101'
      },

    • update operation shows a comment only on the command.q.$comment field in the system.profile collection.

      op: 'update',
      ns: 'db101.Bets',
      command: {
      q: {
      _id: ObjectId("61a9db4b3bd34e4f68fb9abc"),
      '$comment': 'test-dba'
      },
      u: { '$set': { odds: 0.5 } },
      multi:… 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

    0 comments  ·  Query and Aggregation Pipeline  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

14. restricted mode for database

    database in restricted mode can very helpful .. so we can carry out , lock users out, rebuild indexes, compact and other admin tasks.

    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

    2 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

15. Support for CentOS Stream 8 in MongoDB OPS Manager version 5.x

    Per the Server Support Matrix https://www.mongodb.com/try/download/ops-manager support for CentOS Stream 8 is not al.
    We would like to see the currently supported MongoDB OPS Manager version 5.x available on the CentOS Stream 8 distribution.

    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

    0 comments  ·  Security  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

16. NoTableScan at the collection level

    NoTableScan at the collection level instead of mongod level.

    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

    1 comment  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

17. Please report mixed-type numeric _id fields in $merge stage error

    Posting this idea at the request of one of the Jira users. You can find more technical details about this in the Jira issue:

    https://jira.mongodb.org/browse/SERVER-61613

    The gist of it is that I may have two collections, b2 and b3, that are not distinguishable in the Mongo Shell, like this:

    db.b2.find()
    
    [
    
      { _id: 1, created: ISODate("2021-11-18T23:16:33.149Z") },
    
      { _id: 2, created: ISODate("2021-11-18T23:16:33.149Z") }
    
    ] 
    
    db.b3.find()
    
    [
    
      { _id: 1, created: ISODate("2021-11-18T22:53:02.113Z") },
    
      { _id: 2, created: ISODate("2021-11-18T22:53:02.113Z") }
    
    ] ```
    
    When I merge each into a collection `pg` with this syntax:
    
    

    db.pg.aggregate([{$merge: {into: "b3", whenMatched: "merge", whenNotMatched: "fail"}} ]);
    ```

    , it reports a cryptic message:

    MongoServerError: $merge failed to update the matching document, did you attempt to modify the id or the shard key? :: caused by :: Performing an update on the path 'id' would modify the immutable field '_id '

    The pg collection is just an example that in real life is a an aggregation stage before $merge.

    The underlying issue is that b2._id is BSON int and b3._id is BSON double, which is not visible in Mongo Shell, and that Mongo DB server fails to recognize numeric types that would work just fine in other comparisons, like queries.

    Please report an error or a warning that _id fields in merged collections are of different numeric types, so it would be clear what the problem is, which will save people a lot of time trying to figure out why the type of _id is being changed.

    Given that _id is immutable, people would have to drop the collection and recreate it, which may be quite tricky for large databases. If there was a tool to do that or if the server would recognize compatible numeric values and report the error only when numeric types cannot be coalesced, it would also be helpful.

    Posting this idea at the request of one of the Jira users. You can find more technical details about this in the Jira issue:

    https://jira.mongodb.org/browse/SERVER-61613

    The gist of it is that I may have two collections, b2 and b3, that are not distinguishable in the Mongo Shell, like this:

    db.b2.find()
    
    [
    
      { _id: 1, created: ISODate("2021-11-18T23:16:33.149Z") },
    
      { _id: 2, created: ISODate("2021-11-18T23:16:33.149Z") }
    
    ] 
    
    db.b3.find()
    
    [
    
      { _id: 1, created: ISODate("2021-11-18T22:53:02.113Z") },
    
      { _id: 2, created: ISODate("2021-11-18T22:53:02.113Z") }
    
    ] ```
    
    When I merge each into a collection `pg` with this syntax:
    
    

    db.pg.aggregate([{$merge: {into: "b3", whenMatched: "merge", whenNotMatched: "fail"}} ]);… 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

    0 comments  ·  Indexes  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

18. multiple centersphere as a geometry for geowithin

    im looking at one of my queries that a system regularly runs and some times we look for records that are within up to 250 different centerspheres, i wornder if we could enable, like geowithin has the ability to support multiple poligons, we could enable multiple centerspheres ,
    
    
$match: {{'location':{
"$geoWithin" : {
"$centerSphere" : [[ 14.4321, -9.4321], 2.5232135647961246e-05]
}
}}, {'location':{
"$geoWithin" : {
"$centerSphere" : [[ 14.4321, -9.4321], 2.5232135647961246e-05]
}
}}, ...}


    we could do :
    ```
    $match: {'location':{
    "$geoWithin" : {
    "$centerSpheres" : [
    [[ 14.4321, -9.4321], 2.5232135647961246e-05] ,
    [[ 14.4321, -9.4321], 2.5232135647961246e-05],
    ...
    ]

        } 
    }}
    

    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

    0 comments  ·  Query and Aggregation Pipeline  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

19. There is a specific collection that I need more performance than others. Is there a way to assign more ram/memory to a specific collection?

    There is a specific collection that I need more performance than others. Is there a way to assign more ram/memory to a specific collection?

    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

    0 comments  ·  Performance  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

20. Make IAM database user authentication compatible with AWS SSO

    We are in the process of implementing AWS SSO across our Organisation and wanted to tie this in with mongodb-aws for database authentication.
    Unfortunately we have been informed the 2 services are not compatible.

    This would be a really useful add on to improve management of our systems.

    4 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 →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close