303 results found

1. $dateDiff operator should be useful to calculate age

   In the documentation it says: " For example, two dates that are 18 months apart would return 1 year difference instead of 1.5 years.". But if startDate is 2021-08-01 and endDate is 2023-02-01, the result is 2 years difference. I think it should be good if this operator could be used to calculate the age.

   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

   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. Make consistent use of system-wide CA certificate store

   Please make the use of system-wide CA certificate store the same in all tool/commands.

   • If tls.CAFile is not specified in mongod/mongos configuration then the system-wide CA certificate store will be used.

   • If --sslCAFile is not specified in mongoimport/mongoexport tool then the system-wide CA certificate store will be used - but this behavior is not documented.

   • For mongosh you have to specify option --tlsUseSystemCA is you like to use the system-wide CA certificate store. I did not check how it is/was working in legacy mongo shell.

   • For command Mongo() (https://www.mongodb.com/docs/v6.0/reference/method/Mongo/), I was not able to find out, how to use the system-wide CA certificate store

   • If you add tlsUseSystemCA=true to connection string URI, then you get an error

   So, there are several ways for doing that. There should be a consistent way across all tools

   Please make the use of system-wide CA certificate store the same in all tool/commands.

   • If tls.CAFile is not specified in mongod/mongos configuration then the system-wide CA certificate store will be used.

   • If --sslCAFile is not specified in mongoimport/mongoexport tool then the system-wide CA certificate store will be used - but this behavior is not documented.

   • For mongosh you have to specify option --tlsUseSystemCA is you like to use the system-wide CA certificate store. I did not check how it is/was working in legacy mongo shell.

   • For command Mongo() (https://www.mongodb.com/docs/v6.0/reference/method/Mongo/), I was not able to find out, how to… 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

   1 comment  ·  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

3. Clustered Collection TTL on _id should support ObjectId.

   Clustered Collections have the ability to expire on the _id field, this would be really helpful if it could use the timestamp portion of the ObjectId.

   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

   0 comments  ·  Indexes  ·  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. Support Two Array Fields in Compound Indexes

   Hi,

   I've come across a lot of use cases where the business logic has demanded unique constraints on 1-2 fields that have been modeled as arrays on documents. The cases that only contain a single array field is already taken care of using unique indexes in MongoDB, however the cases with 2 array fields have required application level constraints since the database only supports a single array field in compound indexes. While multiple arrays in a single index would massively increase the size of the indexes, it would be very helpful if it would still be possible. If there are other limitations that makes it difficult to implement support for N number of array fields, then my request would be to increase the limit from 1 to 2, as this would solve all of the cases that I've encountered (and any reasonable cases that I could think of).

   Thanks in advance,

   Hi,

   I've come across a lot of use cases where the business logic has demanded unique constraints on 1-2 fields that have been modeled as arrays on documents. The cases that only contain a single array field is already taken care of using unique indexes in MongoDB, however the cases with 2 array fields have required application level constraints since the database only supports a single array field in compound indexes. While multiple arrays in a single index would massively increase the size of the indexes, it would be very helpful if it would still be possible. If there are… 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

   0 comments  ·  Indexes  ·  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. Query Planner needs a timeOut set as a Database parameter.

   Query Planner needs a timeOut set as a Database parameter.

   We see App queries timing out on Query planner taking >1 sec. Whilst this can be avoided by setting maxTimeMS at client end - this is more of a setting for the overall query and not just the query planner - Also, this comes at the risk of closing/timing out the actual query (cursor) which is not our need.

   We only want the query planner itself to have a specific - set/customisable timeout and the query to keep running selecting one/any if the plans run thus far without timing out overall.

   Please refer: Case 01007144

   Query Planner needs a timeOut set as a Database parameter.

   We see App queries timing out on Query planner taking >1 sec. Whilst this can be avoided by setting maxTimeMS at client end - this is more of a setting for the overall query and not just the query planner - Also, this comes at the risk of closing/timing out the actual query (cursor) which is not our need.

   We only want the query planner itself to have a specific - set/customisable timeout and the query to keep running selecting one/any if the plans run thus far without timing out… 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

   0 comments  ·  Administration  ·  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. We need to be able to use $[<identifier>] and "$setOnInsert" in the same command

   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.

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

   0 comments  ·  Other  ·  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. hint support for $graphLookup

   Currently you can supply a hint to the aggregation call in order to tell MongoDB to use a specific index for the initial $match. But there is currently no way to specify which index to use for a $graphLookup later in the pipeline.

   I would like an optional hint property on the $graphLookup stage.

   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

   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

8. Add numerically-ordered index feature which forces a field to maintain ordering

   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.

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

   0 comments  ·  Indexes  ·  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. Add pipeline stage for "downsampling" data

   Down sampling is an extremely common operation used when plotting time-series data on graphs when there is too much data to get a good looking/meaningful graph. This would pick and choose "important" data points based on an algorithm such as "Largest-Triangle-Three-Buckets" (https://skemman.is/bitstream/1946/15343/3/SS_MSthesis.pdf) instead of returning the entire data set.

   Not only would this make prettier graph but it will also reduce the overall payload returned from the data thus reducing network related latency.

   This would be an awesome addition to timeseries!

   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

   0 comments  ·  Time Series  ·  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. Support readOnly in Json Schema Validation

    Support the readOnly property for json schema validation to make certain fields immutable (or the entire document) after creation.

    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

    0 comments  ·  Data Models  ·  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. Use dedicated interface for replication and balancing

    Like many other big database system, MongoDB may support to specify dedicated interfaces for replication and/or for the balancer (sharding)

    Currently you can configure replication sets and shards members only by single hostname/IP-Address, i.e. all data is transmitted over the same network interface.

    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

    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

12. Make it clear an index not on present on all shards

    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.

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

    0 comments  ·  Indexes  ·  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. CSFLE - Enable aggregation stages for non-encrypted collections

    When encrypting any collection with CSFLE, aggregation is not allowed on non-encrypted collections.

    The official recommendation is to maintain 2 clients: 1 for CSFLE and 1 for when aggregation is needed. How is this an acceptable solution?

    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

    0 comments  ·  Encryption  ·  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. Preserve field order in $merge

    Filed on behalf of https://jira.mongodb.org/browse/SERVER-63853:

    A variety of formats require strict adherence to the sequence of fields, such as bioinformatics

    Files of such formats are often very large and contain nested structures, so it is convenient to use them as collections. But to keep the data belonging to the above specs, it is necessary to keep the arrangement of the fields. Unfortunately, aggregations with saving results to another DB lose original arrangement.

    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

    0 comments  ·  Other  ·  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 converting between UUID and String

    It would be nice to have UUID support for $convert and $toString functions - and maybe also having a new $toUuid function added.

    We have documents with UUIDs stored as UUIDs, and others where they are stored as Strings - and need to $lookup a document with an UUID type _id from a document where that uuid is stored as a String. As far as I can tell that is currently not possible.

    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

    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

16. Tiered TTL for time series collection based on granularity

    Currently time series collections have a single TTL across all inherent granularities. It would be great to specify a TTL for each granularity. For example:

    For seconds: 1 week
    For hours: 1 month
    Others: never

    Course information should be held longer than finer information in some cases - currently they all fall under the main TTL specified.

    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

    0 comments  ·  Time Series  ·  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. 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

18. Support for MongoDB Server on Ubuntu 21.04.

    Per the MongoDB Server Supported Platforms Matrix support for Ubuntu 21.04 is not yet available.
    We would like to see the currently supported MongoDB Server versions available on the Ubuntu 21.04 LTS distribution which was released on 22 April 2021

    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

    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

19. Provide a KRB5_KTNAME setParameter or other config setting

    The Kerberos keytab file is specified in the KRB5_KTNAME environment variable.

    Could a setParameter or other config file setting "krb5KtName" be provided to allow this to be set?

    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

    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

20. Ability to replicate the data within a cluster to another cluster

    Two different scenarios. One scenario is to have a DR cluster. 2 independant clusters that are one way synced. As of right now, a custom CDC solution (custom code + Kafka) is needed to achieve this.
    Another is because of latency and the requirement for data to be stored in 2 different data center, 2 indepentant mongoDB clusters that are two way synced. As of right now, a custom CDC solution (custom code + Kafka) is needed to achieve this.

    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

    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