321 results found

1. 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

   Submit Rating

2. 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

   Submit Rating

3. 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

   Submit Rating

4. 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

   Submit Rating

5. 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

   Submit Rating

6. 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

   Submit Rating

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

   Submit Rating

8. 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

   Submit Rating

9. 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

   Submit Rating

10. 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

    Submit Rating

11. Add a $median accumulator

    There is the $avg operator that returns the average of a set of values. Why not a $median?

    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

    planned  ·  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

    Submit Rating

12. 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

    Submit Rating

13. 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

    Submit Rating

14. 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

    Submit Rating

15. Record running queries at the time of a failover

    I recently observed some failovers in a replica set that may have been related to long-running queries. However, since these queries happened only sporadically, it was hard to track them down. Since the queries didn't finish, they weren't present in the logs at the time of the crash.

    It would be useful if it could be possible to somehow capture the long-running queries that were running at the time that something went wrong. I recognize that this is potentially impossible, since once something has gone wrong it can be difficult to do anything.

    We ended up being able to diagnose this by watching the real-time stats tab in Cloud Manager at the right time, though we aren't certain. This suggests that maybe this could be some Atlas feature. I don't know how real-time stats works, but if can run when the user isn't watching it, would it be possible to record slow queries at the time of a failover? I could also imagine this as some server feature, where the server would make some effort to write long-running queries to its logs when it becomes a secondary. There may not be a guarantee that this would work, but in the cases where it did it would be useful.

    I recently observed some failovers in a replica set that may have been related to long-running queries. However, since these queries happened only sporadically, it was hard to track them down. Since the queries didn't finish, they weren't present in the logs at the time of the crash.

    It would be useful if it could be possible to somehow capture the long-running queries that were running at the time that something went wrong. I recognize that this is potentially impossible, since once something has gone wrong it can be difficult to do anything.

    We ended up being able to diagnose… 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  ·  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

    Submit Rating

16. Create and use db links in Mongodb

    Allow Mongodb to access an external database for:
    1.select identifiers on an external rdbms (ex: postgres, sqls, oracle, ...)
    2.use these identifiers to perform aggregations in Mongodb

    Currently, it is necessary to use a third-party tool that connects to several data sources to perform these actions.
    The idea is to be able to perform these "joins" only in Mongodb CLI.

    Regards,
    Jerome

    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

    Submit Rating

17. Document known breaking change in JavaScript Engine

    If a new version of MongoDB will include a new version of MozJS (ex https://jira.mongodb.org/browse/SERVER-29286) and this version will break any existing scripts it would be ideal if this was documented.

    For example, with MongoDB 4.2 "value".contains() no longer worked in scripts and had to be converted to "value".includes()

    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

    Submit Rating

18. VPC between ATLAS/MongoDB/AWS and Heroku/AWS

    Would be a great great feature if we can create a VPC between ATLAS/MongoDB/AWS and Heroku/AWS.
    Thanks.
    Adailton Silva

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

    Submit Rating

19. Add option to repair a single collection

    Add support for repairing a single collection instead of what is currently available to repair an entire database via db.repairDatabase()

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

    Submit Rating

20. Aggregate $accumulator 'Combine' stage for sharded collections

    After the ‘accumulate’ stage has run against each document on a shard it would be extremely useful to run a script on the shard against the state to reduce the state down to something smaller before passing the final state over the network back to mongos for the ‘merge’. (Over in the Elastic camp they call this the ‘combine_script’).

    Scenario:
    I have a customer orders database sharded by the Customer ID (meaning all data relating to any specific customer is kept on the same shard - so customers don’t need to be ‘merged’ between shards). I can write an accumulator to perform processing across all customer orders on the shard and the wish to perform further processing to reduce the state (containing data spanning various customer orders) down to a minimal state (mostly aggregated customer stats) to then be aggregated by mongos. I wish to avoid copying multiple large state objects (from each shard) across network to the ‘merge’ script on mongos.

    After the ‘accumulate’ stage has run against each document on a shard it would be extremely useful to run a script on the shard against the state to reduce the state down to something smaller before passing the final state over the network back to mongos for the ‘merge’. (Over in the Elastic camp they call this the ‘combine_script’).

    Scenario:
    I have a customer orders database sharded by the Customer ID (meaning all data relating to any specific customer is kept on the same shard - so customers don’t need to be ‘merged’ between shards). I can write an accumulator… 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  ·  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

    Submit Rating