295 results found

1. Add Event Stream Features (Apache Kafka, NATS Streaming)

   I thought it would be great if mongodb can support an event streaming(event bus) feature.
   Existing popular event streaming services(AWS Kinesis, NATS Streaming, Apache Kafka) can persist data which is somewhat like a database.

   Its great for debugging, data logging for later uses such as machine learning. Since I can see the full flow of the data and its changes.

   But there are two downside with most even streaming services.
   1. Its very difficult to query the data.
   2. "Eventual Consistency" issue when dealing programmatic errors(bugs). Most event streams have this nice feature, which keeps sending the same event to a subscriber until the subscriber acknowledges that the event has been published. Now this is really great in terms of temporary issues(network problem, service restart due to deployment, etc.). But if the cause of failure is a bug, which needs fixing by a developer, the event bus should not continuously send same event again and again.

   To solve this issue, I made a micro service that subscribes to all events and store the events in mongodb, basically I store the event data both in mongo and stream service.
   Now its super easy to query(since "event chain" is a tree structure for every child event I store the parent event Id)
   Also I dont only store events but event errors with its parent event Id and error stack trace. With this I made a small feature that counts the number of duplicate errors. When the number of duplicate error exceeds a certain number, we can assume that its not a temporary error and so the event bus is programmatically acknowledged.
   After the developer fixes the issue the developer can relaunch the same event based on what is stored in mongodb.
   Now one major issue people might come up with this solution is that a lot of data is generated in mongo, which are not queried regularly.
   Well in this case I think I can make use of mongodb data lake/ For example I could only store recent 7 days of events in mongodb and after 7days I could make a data pipeline that exports data to S3 and if I need to query I would use mongodb data lake.

   After building this service and duplicating the events from the event stream to mongodb, I thought it would be great if mongodb supports a built in feature. This feature would be especially great for mongodb compared to other databases(relational) because events in general are objects(documents)

   I thought it would be great if mongodb can support an event streaming(event bus) feature.
   Existing popular event streaming services(AWS Kinesis, NATS Streaming, Apache Kafka) can persist data which is somewhat like a database.

   Its great for debugging, data logging for later uses such as machine learning. Since I can see the full flow of the data and its changes.

   But there are two downside with most even streaming services.
   1. Its very difficult to query the data.
   2. "Eventual Consistency" issue when dealing programmatic errors(bugs). Most event streams have this nice feature, which keeps sending the same event 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  ·  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. Performance problem with compound index using doubles, with range filtering

   It looks like there may be a problem when using doubles in a compound index and using range-test filters against all of them in a query.
   The problem we see from the explain plans is that far more keys are being examined that there should be and this leads to poor performance.
   If we switch to using a similar setup but with integers instead, we don’t see the problem.

   See the second part of this ticket for full details

   https://support.mongodb.com/case/00659614

   We have a document that looks like this –

   {
   "id" : ObjectId("5e2ab24eca314f10b486d827"),
   "attributes" : [
   {
   "attributeCode" : "attributesitemsGeometry",
   "boundingBox" : {
   "lonMin" : -1.93181854783035,
   "latMin" : 52.1718902305398,
   "lonMax" : -1.9244498979136,
   "latMax" : 52.1749938832085
   }
   }
   ]
   }

   With a compound index like this –

   {
       "v" : 2,
       "key" : {
           "attributes.boundingBox.lonMin" : 1,
           "attributes.boundingBox.lonMax" : 1,
           "attributes.boundingBox.latMin" : 1,
           "attributes.boundingBox.latMax" : 1        },
       "name" : "itemVersions_designCode_collection_attributeCode_boundingBox_date",
       "ns" : "customerBlah.itemVersions"
   }
   

   And we make queries with range filters like this

   "attributes" : {
   "$elemMatch" : {
   "$and" : [

   {
   "boundingBox.latMin" : {
   "$lte" : 52.0751028974155
   }
   },
   {
   "boundingBox.lonMin" : {
   "$lte" : -1.92557202436271
   }
   },
   {
   "boundingBox.latMax" : {
   "$gte" : 52.0729000493818
   }
   },
   {
   "boundingBox.lonMax" : {
   "$gte" : -1.92931078813729
   }
   }

   It looks like there may be a problem when using doubles in a compound index and using range-test filters against all of them in a query.
   The problem we see from the explain plans is that far more keys are being examined that there should be and this leads to poor performance.
   If we switch to using a similar setup but with integers instead, we don’t see the problem.

   See the second part of this ticket for full details

   https://support.mongodb.com/case/00659614

   We have a document that looks like this –

   {
   "id" : ObjectId("5e2ab24eca314f10b486d827"),
   "attributes" : [
   {
   "attributeCode" :… 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

3. Too many keys in 2dsphere index when used on geoJson within arrays

   Mongo support have asked me to raise this bug as an improvement idea because they see it as an edge case.
   The issue is here and includes more details:

   https://support.mongodb.com/case/00659614

   In summary, if you have a geoJson sub document that sits within an array, and you index it using the 2dspehere index, you get keys duplicated for every element in the array.

   For example, if you have geoJson that represents a big 4,500 vertex polygon, and you put it within an array element, if the array has only one element I see 20 keys generated, which is good. But if you have another element in the array that doesn’t have any geoJson, another 20 keys are generated, now totaling 40 keys for that document.

   In our application this bug can cause the index memory requirements for 2dsphere to become a serious concern.

   We have stopped using the index and developed an alternative.

   Mongo support have asked me to raise this bug as an improvement idea because they see it as an edge case.
   The issue is here and includes more details:

   https://support.mongodb.com/case/00659614

   In summary, if you have a geoJson sub document that sits within an array, and you index it using the 2dspehere index, you get keys duplicated for every element in the array.

   For example, if you have geoJson that represents a big 4,500 vertex polygon, and you put it within an array element, if the array has only one element I see 20 keys generated, which is good. But if… 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

4. Making Elections Faster.

   Election is an expensive operation. We can avoid the elections if we can enforce some priority-based ordering on who shall become primary if the current primary fails.
   Specifically, we can keep a node with second highest priority in the data center of the most preferred primary. Usually, the network failures within the data centers are less probable than across the data centers. So, it is reasonable to believe that if the second preferred member loses the contact with current primary, it is the primary node which has failed and not the network. As a supplement, we can also have redundant network connection between the two. So, we do not need to wait for 10 seconds to detect that it is a node failure. Write operations can immediately shift to the second preferred member and this would make system “more” available for writes.

   Election is an expensive operation. We can avoid the elections if we can enforce some priority-based ordering on who shall become primary if the current primary fails.
   Specifically, we can keep a node with second highest priority in the data center of the most preferred primary. Usually, the network failures within the data centers are less probable than across the data centers. So, it is reasonable to believe that if the second preferred member loses the contact with current primary, it is the primary node which has failed and not the network. As a supplement, we can also have redundant… 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

5. Is there any limitation on size of query in pipeline (character in query, not data)

   I have an aggregate query, when the character in pipeline over 21066 character, the result return wrong format that the pipeline expected. So I wonder is there any limitation on size of query in pipeline?

   My case is:
   Query: [
   "$match":{"profileID": {"$in": ['', .....]}},
   {"$group":{"_id":"$profileID","materialLevel2":{"$sum":{"$cond":[{"$and":[{"$eq":["$expenseL2","true"]},{"$eq":["$expenseL3","false"]},{"$eq":["$expenseL4","false"]}]},1,0]}},"materialLevel3":{"$sum":{"$cond":[{"$and":[{"$eq":["$expenseL3","true"]},{"$eq":["$expenseL4","false"]}]},1,0]}},"materialLevel4":{"$sum":{"$cond":[{"$eq":["$expenseL4","true"]},1,0]}}}}
   ]

   The true result is:
   [{
   "_id" : "000.03.50.H29",
   "materialLevel2" : 1.0,
   "materialLevel3" : 1.0,
   "materialLevel4" : 2.0
   },...]

   But when the length of query greater than 21066 character, the result of query is:

   [{
   "profileID" : "00.00.00.PTT",
   "expenseL2" : "true",
   "expenseL3" : "true",
   "expenseL4" : "false"
   },....]

   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

   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

6. Support concise correlated queries for $graphLookUp

   Similar to $lookUp, support concise correlated queries for $graphLookUp.

   It would allow adding a $project stage to reduce overhead.

   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

7. Capture pre-images for ONLY specified change events

   Currently, pre-images are captured for all updates, replacements and deletes on a given collection.

   Ask: Enable capture of pre-images for ['DELETED', ...] documents only.

   Context: A customer uses a collection for ingestion, where 16-20M documents are ingested every 20 minutes. Documents are indexed with Elastic Search upon insertion, and are removed from Elastic Search upon deletion. However, the ingestion process requires subsequent operations: an average of 30 updates are made on each document, and the customer doesn't want to pay the penalty of generating pre- and post-images on updates.

   Impact: Updating a collection of 80GB (20M docs of 4kb each) 30 times per document unnecessarily creates a Change Stream storage requirement of 2.4TB. This prevents the customer's adoption of full document change streams.

   Currently, pre-images are captured for all updates, replacements and deletes on a given collection.

   Ask: Enable capture of pre-images for ['DELETED', ...] documents only.

   Context: A customer uses a collection for ingestion, where 16-20M documents are ingested every 20 minutes. Documents are indexed with Elastic Search upon insertion, and are removed from Elastic Search upon deletion. However, the ingestion process requires subsequent operations: an average of 30 updates are made on each document, and the customer doesn't want to pay the penalty of generating pre- and post-images on updates.

   Impact: Updating a collection of 80GB (20M docs of 4kb each) 30… 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

   2 comments  ·  Change Streams  ·  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

8. MongoDB Audit Log Missing Failed and Successful Command Execution Flag

   When you initially create a database account…..this action will be logged in the database audit logs as configured, however when you try to re-attempt to create the account again….a normal error message will be displayed as shown below:

   db.createUser( {user: "test111_3",pwd: "emad123",roles: [ { role: "readWrite", db: "admin" } ]})

   When examining the audit logs the two entries are identical in results which shouldn’t be the case….I think the flag “result” when command executed failed should have a different value to distinguish successfully executed commands from failed executed commands:

   { "atype" : "createUser", "ts" : { "$date" : "2024-08-30T13:04:59.535+03:00" }, "uuid" : { "$binary" : "A1DPqlPsT+u7xH2St9yiug==", "$type" : "04" }, "local" : { "ip" : "127.0.0.1", "port" : 27017 }, "remote" : { "ip" : "127.0.0.1", "port" : 65266 }, "users" : [ { "user" : "mongo", "db" : "admin" } ], "roles" : [ { "role" : "root", "db" : "admin" } ], "param" : { "user" : "test1113", "db" : "admin", "roles" : [ { "role" : "readWrite", "db" : "admin" } ] }, "result" : 0 }
   { "atype" : "createUser", "ts" : { "$date" : "2024-08-30T13:06:10.918+03:00" }, "uuid" : { "$binary" : "A1DPqlPsT+u7xH2St9yiug==", "$type" : "04" }, "local" : { "ip" : "127.0.0.1", "port" : 27017 }, "remote" : { "ip" : "127.0.0.1", "port" : 65266 }, "users" : [ { "user" : "mongo", "db" : "admin" } ], "roles" : [ { "role" : "root", "db" : "admin" } ], "param" : { "user" : "test1113", "db" : "admin", "roles" : [ { "role" : "readWrite", "db" : "admin" } ] }, "result" : 0 }

   When you initially create a database account…..this action will be logged in the database audit logs as configured, however when you try to re-attempt to create the account again….a normal error message will be displayed as shown below:

   db.createUser( {user: "test111_3",pwd: "emad123",roles: [ { role: "readWrite", db: "admin" } ]})

   When examining the audit logs the two entries are identical in results which shouldn’t be the case….I think the flag “result” when command executed failed should have a different value to distinguish successfully executed commands from failed executed commands:

   { "atype" : "createUser", "ts" : { "$date" : "2024-08-30T13:04:59.535+03:00" },… 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  ·  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

9. upgrade src/third_party/gperftools ≥ 2.10

   gperftools new version support new architecture

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

10. Support hex conversion and binary operators in aggregation framework

    The aggregation framework lacks function for HEX <-> Number conversion and binary operations. Such functions are common in almost every programming language.

    Typically and most required operations would be:

    • convert Int/Long to Hex
    • convert Hex to Int/Long
    • Create BinData from Hex string
    • Get Hex string of BinData
    • Binary AND
    • Binary OR
    • Binary XOR
    • Binary NOT (i.e. complement)

    Some of these functions are available in mongo shell or in Bitwise Query Operators but they do not exist in aggregation framework.

    For details see https://jira.mongodb.org/browse/SERVER-55386

    This request becomes more urgent, because starting in MongoDB 8.0, server-side JavaScript functions ($accumulator, $function, $where) are deprecated.

    The aggregation framework lacks function for HEX <-> Number conversion and binary operations. Such functions are common in almost every programming language.

    Typically and most required operations would be:

    • convert Int/Long to Hex
    • convert Hex to Int/Long
    • Create BinData from Hex string
    • Get Hex string of BinData
    • Binary AND
    • Binary OR
    • Binary XOR
    • Binary NOT (i.e. complement)

    Some of these functions are available in mongo shell or in Bitwise Query Operators but they do not exist in aggregation framework.

    For details see https://jira.mongodb.org/browse/SERVER-55386

    This request becomes more urgent, because starting in MongoDB 8.0, server-side JavaScript functions ($accumulator, $function, $where) are… 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  ·  Other  ·  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

11. $sort should allow 0 as argument meaning "no sort"

    The $sort operator and aggregation stage should allow 0 (possibly also null) as an argument for the field sort order, meaning, "Don't sort."
    This allows a variable to be passed in that can conditionally skip the sort operation, in addition to the present specification, in which a variable can only choose ascending or descending sort.

    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

12. Easier way to troubleshoot storage use size discrepancy across nodes in the same replica set

    While initial sync may potentially help on this topic, it would be great if the product has any easier way to identify the cause of significantly different storage use size (so to give a better confidence if initial sync is going to 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  ·  Storage (Wired Tiger)  ·  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

13. Feature to perform Machine Learning predictive analysis and classification in MongoDB

    I want to bring the machine learning compute and predictive analysis into MongoDB atlas. Instead of ETL my data out of Atlas to achieve this, I will reduce my architectural complexity by having an aggregation operator that does this on my documents stored in Atlas.

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

    Today $unionWith aggregation command is executed sequentially. EG first we query collection A and then collection B and then the union occurs.
    The process should be parallelized so the query part will run in parallel while the union will be done as best effort tree merge try to speed up the overall Elapsed Time of the query

    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

15. Scheduled stepdown for smoother primary election

    Stepdown is a great tool that allows us to keep clusters operating smoothly. We use it for example when we want to perform some maintenance work on the host where the primary is currently running, to perform a rolling upgrade, and in many other cases we need to switch the primary to another node.

    While usually electing a new primary is fast enough, for clusters with very high write traffic, it sometimes unfortunately leads to write errors on the application side. The reason is that drivers need to disconnect from the previous primary and connect to the new one, and this takes time. All write attempts at this time end with an error. Of course those operations can be retried after a short time, but it seems to me that this situation could be avoided fairly easily.

    Here's my idea:
    - We add an optional parameter to the stepDown method, let’s name it: electionEffectiveTimeSeconds. If we do not set it, stepDown works normally - as before,

    • The new primary is elected, but the cluster and drivers do not use it as a primary yet, instead they wait for electionEffectiveTimeSeconds seconds after the election is done,

    • Until then, the previous primary handles write operations,

    • In the meantime, all cluster nodes and drivers receive information about the new primary and when the change will take effect - based on electionEffectiveTimeSeconds,

    • This will allow all parties to properly prepare for the switchover, which should minimize the time of unavailability of the primary,

    • When the time expires, clusters and drivers change primaries to the new node.

    The key element will be to determine the optimal range for this new parameter. On the one hand, it must be big enough to give enough of time to spread the information through the cluster and drivers. On the other hand, it must not be too long, because there is a risk that - during that time - the new elected primary will catch a lag and will not be able to become a primary. In this case, however, it could try one more time, and if that fails also, then perform a normal stepdown for a third time.

    I think this method would be useful during all stepdowns, which are planned in advance and it is not necessary to happen immediately.

    Stepdown is a great tool that allows us to keep clusters operating smoothly. We use it for example when we want to perform some maintenance work on the host where the primary is currently running, to perform a rolling upgrade, and in many other cases we need to switch the primary to another node.

    While usually electing a new primary is fast enough, for clusters with very high write traffic, it sometimes unfortunately leads to write errors on the application side. The reason is that drivers need to disconnect from the previous primary and connect to the new one, and… 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  ·  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

16. Add Relaxed mode support for the $out operator

    Add Relaxed mode support for the $out operator.
    *and include as option in the existing drivers

    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

17. Write parts of database engine in ZIG

    Zig is a zero-dependency, drop-in C/C++ compiler that supports cross-compilation out-of-the-box. Implementing some parts of MongoDB database engine core in ZIG might brings some performance improvements.

    https://ziglang.org/

    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  ·  Other  ·  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. Aggregations should allow an empty sort stage instead of returning an error

    When you run an aggregation pipeline that contains an empty sort stage (like {"$sort": {}}) MongoDB returns the error message "$sort stage must have at least one sort key". It would be really helpful if such a stage would work and simply not apply any sorting at all.

    For one this would be more consistent with a find operation (e.g. db.runCommand({"find": "test", "sort": {}}) or db.test.find({}, {}, {"sort": {}})) which does not return an error but simply does not sort the results. More importantly it would also make it easier for developers and frameworks to dynamically generate the aggregation stages.

    For example: If you already have a JSON object that contains the fields to sort by and their sort order, you could simply put this object into a sort stage and add it to the pipeline. Currently you first have to make sure that the object is not the empty object and only then add the sort stage to the pipeline.

    Another example: In Spring Data MongoDB you can explicitly state that you don't want any sorting. When you use this Sort.unsorted() in a sort aggregation stage, it will generate the empty sort stage mentioned above ({"$sort": {}}). This currently leads to an error. I have reported this error here (https://github.com/spring-projects/spring-data-mongodb/issues/4703) but for them it is also very cumbersome to modify their aggregation pipeline generation only to filter out an empty sort stage.

    Hence it would be much better to solve this issue in MongoDB itself.

    When you run an aggregation pipeline that contains an empty sort stage (like {"$sort": {}}) MongoDB returns the error message "$sort stage must have at least one sort key". It would be really helpful if such a stage would work and simply not apply any sorting at all.

    For one this would be more consistent with a find operation (e.g. db.runCommand({"find": "test", "sort": {}}) or db.test.find({}, {}, {"sort": {}})) which does not return an error but simply does not sort the results. More importantly it would also make it easier for developers and frameworks to dynamically generate the… 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

19. Query comment or metadata in change stream event

    Our application is using change stream events to publish changes as kafka events for our customers. Sometimes we are in need to decide if an event should be send by kafka or not. Right at the moment the only way would be to decide based on additional fields on our document.

    It would be nice if there is an opportunity to include query comments to change stream events or some kind of meta data to get some info about the origin of the operation. This would be useful, to decide without any need to add additional fields to our data model.

    Our application is using change stream events to publish changes as kafka events for our customers. Sometimes we are in need to decide if an event should be send by kafka or not. Right at the moment the only way would be to decide based on additional fields on our document.

    It would be nice if there is an opportunity to include query comments to change stream events or some kind of meta data to get some info about the origin of the operation. This would be useful, to decide without any need to add additional fields to our data… 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  ·  Change Streams  ·  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. allow mongosync to migrate few field from source to destination for collection in database

    right now mongosync will migrate all the fields from source to destination based on filter or non filter setting but there is no way to move few field out of all field for all document

    to migrate few field from source to destination for collection in database with default primary key field (_ID )

    requesting the feature in new mongosync 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

    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