54 results found

1. Normalize maximum time in MS parameter name, maxTimeMS vs max_time_ms

   Currently, some operations such as aggregate() or count_documents use maxTimeMS as parameter name, but others such as the find(), use max_time_ms, so unless you memorize which method uses which nomenclature, you have to check the docs every time.
   This is specially confusing since, for example, find_one() uses max_time_ms but all the find_one_and_...() methods use maxTimeMS.

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

2. CommandStartedEvent::getCommand() not instance of Explainable

   I'm trying to build a verbose mode in our MongoDB wrapper library. I was able to implement debug output leveraging CommandSubscriber interface. This part works.
   However what I would also like to do is create support for automatic explaining of queries that are being executed. This is not possible due to inconsistency in MongoDB (php) library.

   • CommandStartedEvent::getCommand() is not an instance of Explainable interface. It's just a deserialized object. There is no way to fetch the original command object to be able to do explain.
   • Neither it is possible to remember such command object when creating it. As these are generated within the library itself. See functions of Collection class for example.

   I'm trying to build a verbose mode in our MongoDB wrapper library. I was able to implement debug output leveraging CommandSubscriber interface. This part works.
   However what I would also like to do is create support for automatic explaining of queries that are being executed. This is not possible due to inconsistency in MongoDB (php) library.

   • CommandStartedEvent::getCommand() is not an instance of Explainable interface. It's just a deserialized object. There is no way to fetch the original command object to be able to do explain.
   • Neither it is possible to remember such command object when creating it. As these 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  ·  PHP  ·  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. Asynchronous variant of IIdGenerator

   We have use cases where IDs assigned to documents are generated by an external service. Communication with the external service is asynchronous. We have created custom IIdGenerator implementations for this purpose, and they work, but unfortunately the IIdGenerator interface is synchronous only. This exposes the known problems with "sync over async" code.

   Obviously we could assign the IDs manually and not rely on using an IIdGenerator, but it would be very convenient to have an async variant of the IIdGenerator interface for this use case.

   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  ·  C#  ·  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. Create a close method on the MongoClient.

   I have run into a situation where threads are not being garbage collected and are causing a serious issue. When we create a database for a specific user, we generate the users’ credentials inside of that database with access only to that database. The problem arises when we need to delete the user and database. The user sometime in the past connected to MongoDB using their credentials which leaves behind an open thread to the MongoDB that is logging into MongoDB once a minute with that users’ credentials. We then come along with our Admin user account and delete the user from the database and then delete the database. This causes the open thread using the now deleted user to start retrying to login using the now deleted users’ credentials over and over every .015 seconds. Our log file store area, about 30Gb fills up within a day with the MongoDB log spew. We need a way to kill a thread once its job is complete, so we don’t get into these runaway situations. I have read that other MongoDB drivers, namely the Java driver, can close the MongoClient. The C# Driver needs the same functionality desperately.Another option is to have the MongoClient stop the thread after 5 try's when the error coming back is user not found.

   I have run into a situation where threads are not being garbage collected and are causing a serious issue. When we create a database for a specific user, we generate the users’ credentials inside of that database with access only to that database. The problem arises when we need to delete the user and database. The user sometime in the past connected to MongoDB using their credentials which leaves behind an open thread to the MongoDB that is logging into MongoDB once a minute with that users’ credentials. We then come along with our Admin user account and delete 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  ·  C#  ·  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. Generic count property in _WriteResult class

   Hi,

   I'm using a MongoDB as a backend for my API and often come to a case where i want to validate whether I updated, inserted or deleted any records. At the moment I use the deletedcount and machtedcount properties in the DeleteResult and UpdateResult object. To provide a more generic way I thought it may makes sense to provide a new property in the generic WriteResult class called affectedrecords or something like that so you can generic react to the result of your database transaction and maybe return a 404 if nothing was updated, deleted or created.
   Let me know what you think and thanks in advance.

   Hi,

   I'm using a MongoDB as a backend for my API and often come to a case where i want to validate whether I updated, inserted or deleted any records. At the moment I use the deletedcount and machtedcount properties in the DeleteResult and UpdateResult object. To provide a more generic way I thought it may makes sense to provide a new property in the generic WriteResult class called affectedrecords or something like that so you can generic react to the result of your database transaction and maybe return a 404 if nothing was updated, deleted or… 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  ·  Python  ·  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. Better handling of circular reference serialization in Java

   Given 2 generic POJOs that include references to each other such as:

   package com.example;
   
   public class Course {
       Student _student;
   
       public void setStudent(Student student) {
         _student = student;
       }
   
       public Student getStudent() {
         return _student;
       }
   }
   
   package com.example;
   
   public class Student {
       private Course _course;
   
       public void setCourse(Course course) {
         _course = course;
       }
       public Course getCourse() {
         return _course;
       }
   }
   

   It would be useful to have a configuration mechanism to prevent Maximum serialization depth exceeded exceptions from being thrown.

   package com.example;
   
   import com.mongodb.ConnectionString;
   import com.mongodb.MongoClientSettings;
   import com.mongodb.client.MongoClient;
   import com.mongodb.client.MongoClients;
   import com.mongodb.client.MongoCollection;
   import com.mongodb.client.MongoDatabase;
   
   import org.bson.Document;
   import org.bson.codecs.configuration.CodecRegistry;
   import org.bson.codecs.pojo.PojoCodecProvider;
   
   import static org.bson.codecs.configuration.CodecRegistries.fromProviders;
   import static org.bson.codecs.configuration.CodecRegistries.fromRegistries;
   
   public class App {
     public static void main(final String[] args) {
       CodecRegistry pojoCodecRegistry = fromProviders(PojoCodecProvider.builder().automatic(true).build());
       CodecRegistry codecRegistry = fromRegistries(MongoClientSettings.getDefaultCodecRegistry(),
       pojoCodecRegistry);
       MongoClientSettings clientSettings = MongoClientSettings.builder()
       .applyConnectionString(new ConnectionString("mongodb://localhost:27017"))
       .codecRegistry(codecRegistry)
       .build();
   
       MongoClient mongoClient = MongoClients.create(clientSettings);
           MongoDatabase database = mongoClient.getDatabase("test");
   
           MongoCollection<Student> students = database.getCollection("students", Student.class);
           MongoCollection<Course> courses = database.getCollection("courses", Course.class);
   
           students.deleteMany(new Document());
           courses.deleteMany(new Document());
   
           Student student = new Student();
           Course course = new Course();
   
           student.setCourse(course);
           course.setStudent(student);
   
           students.insertOne(student);
           courses.insertOne(course);
   
           System.out.println(students.find(new Document()).first());
           System.out.println(courses.find(new Document()).first());
     }
   }
   

   The above would result in the following:

   Exception in thread "main" org.bson.BsonSerializationException: Maximum serialization depth exceeded (does the object being 
   serialized have a circular reference?).
           at org.bson.AbstractBsonWriter.writeStartDocument(AbstractBsonWriter.java:285)
           at com.mongodb.internal.connection.BsonWriterDecorator.writeStartDocument(BsonWriterDecorator.java:48)
           at com.mongodb.internal.connection.LevelCountingBsonWriter.writeStartDocument(LevelCountingBsonWriter.java:42)      
           at com.mongodb.internal.connection.IdHoldingBsonWriter.writeStartDocument(IdHoldingBsonWriter.java:78)
           at org.bson.codecs.pojo.PojoCodecImpl.encode(PojoCodecImpl.java:94)
           at org.bson.codecs.pojo.LazyPojoCodec.encode(LazyPojoCodec.java:47)
           at org.bson.codecs.EncoderContext.encodeWithChildContext(EncoderContext.java:91)
           at org.bson.codecs.pojo.PojoCodecImpl.encodeValue(PojoCodecImpl.java:181)
           at org.bson.codecs.pojo.PojoCodecImpl.encodeProperty(PojoCodecImpl.java:169)
           at org.bson.codecs.pojo.PojoCodecImpl.encode(PojoCodecImpl.java:106)
           at org.bson.codecs.pojo.LazyPojoCodec.encode(LazyPojoCodec.java:47)
           at org.bson.codecs.EncoderContext.encodeWithChildContext(EncoderContext.java:91)
   ....... etc
   

   Given 2 generic POJOs that include references to each other such as:

   package com.example;
   
   public class Course {
       Student _student;
   
       public void setStudent(Student student) {
         _student = student;
       }
   
       public Student getStudent() {
         return _student;
       }
   }
   
   package com.example;
   
   public class Student {
       private Course _course;
   
       public void setCourse(Course course) {
         _course = course;
       }
       public Course getCourse() {
         return _course;
       }
   }
   

   It would be useful to have a configuration mechanism to prevent Maximum serialization depth exceeded exceptions from being thrown.

   package com.example;
   
   import com.mongodb.ConnectionString;
   import com.mongodb.MongoClientSettings;
   import com.mongodb.client.MongoClient;
   import com.mongodb.client.MongoClients;
   import com.mongodb.client.MongoCollection;
   import com.mongodb.client.MongoDatabase;
   
   import org.bson.Document;
   import org.bson.codecs.configuration.CodecRegistry;

   … 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  ·  Java  ·  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. Have the drivers tell us the cost of network connectivity within a query

   Have the drivers tell us 1. total query execution time. 2. how much of total query execution time was network connectivity/latency and 3. how much time was the query on the cluster.

   This would then tell the developers the cost of network connectivity because right now there is no easy way to measure network connectivity impact to the overall execution 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  ·  Java  ·  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. Make The client model serializable

   I am working on a mongodb connector for the Apache Flink project - https://flink.apache.org/

   Internally, Flink is using java serialization to save the records it is working on in a state which in turn used to recover from failures etc, as well as for passing records between different tasks in the pipeline.
   I have noticed the mongodb client model classes are not Serializable for instance, classes such as WriteModel https://github.com/mongodb/mongo-java-driver/blob/master/driver-core/src/main/com/mongodb/client/model/WriteModel.java and its subclasses or the different Options like ReplaceOptions https://github.com/mongodb/mongo-java-driver/blob/master/driver-core/src/main/com/mongodb/client/model/ReplaceOptions.java

   is there a reason for these classes to not be declared Serializable? Is there a way to contribute to the Java driver project by opening a PR that addresses this?

   I am working on a mongodb connector for the Apache Flink project - https://flink.apache.org/

   Internally, Flink is using java serialization to save the records it is working on in a state which in turn used to recover from failures etc, as well as for passing records between different tasks in the pipeline.
   I have noticed the mongodb client model classes are not Serializable for instance, classes such as WriteModel https://github.com/mongodb/mongo-java-driver/blob/master/driver-core/src/main/com/mongodb/client/model/WriteModel.java and its subclasses or the different Options like ReplaceOptions https://github.com/mongodb/mongo-java-driver/blob/master/driver-core/src/main/com/mongodb/client/model/ReplaceOptions.java

   is there a reason for these classes to not be declared Serializable? Is there a way to contribute to 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  ·  Java  ·  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. Multiple collection ACID transactions

   Currently we can update multiple documents with one query if all documents belong to the same collection as shown below;

   dB.collection.bulkWrite([ query1, query2, query3, query4 ])

   This feature is wonderful but it is paramount if mongodb can enable us to use this query or something similar to update multiple documents from different collections with the one query instead of having to send and await each query one at a time as is currently the case.

   The truth is, mongodb only needs to enable this feature of being able to update multiple documents with one query from different collections and then it will certainly be superior to the SQL databases and will get much more market share.

   Currently we can update multiple documents with one query if all documents belong to the same collection as shown below;

   dB.collection.bulkWrite([ query1, query2, query3, query4 ])

   This feature is wonderful but it is paramount if mongodb can enable us to use this query or something similar to update multiple documents from different collections with the one query instead of having to send and await each query one at a time as is currently the case.

   The truth is, mongodb only needs to enable this feature of being able to update multiple documents with one query from different collections and then… 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  ·  Unspecified  ·  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. Serve API endpoint for MongoDB Compatibility Matrix

    This is a feature request for website API calls/endpoints to retrieve the MongoDB Compatibility matrix for each driver language. For example, NodeJS is located here in HTML format https://docs.mongodb.com/drivers/node/current/compatibility/

    It would be helpful to have a programmatic endpoint for the same compat table results. This will help log parsers and aggregators to quickly identify applications and clients that are connecting to deployments with untested or incompatible client 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  ·  Unspecified  ·  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. SnakeCaseElementNameConvention

    Please add support for snake case convention. Snake Case is super popular with API designs.

    https://mongodb.github.io/mongo-csharp-driver/2.13/reference/bson/mapping/conventions/

    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  ·  C#  ·  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. csfle support for zOS

    Please modify your drivers so our java applications can encrypt and decrypt from the mainframe (zOS) UNIX environment. This missing feature is a road-block to our migration to Atlas.

    We have multiple Java applications that run on an IBM mainframe. Those applications read and write into MongoDB collections, like inserting Mainframe data into MongoDB collections. The mongo-crypt driver for CSFLE does not work on the Mainframe UNIX environment.

    Company policy states we have to encrypt all PHI/PII data prior to inserting the data into Atlas.

    I had opened a support ticket with MongoDB and the final reply was you do not support zOS and to put in this request. (Case number 00802484)

    Here is the error message I shared with MongoDB:
    Exception in thread "main" java.lang.UnsatisfiedLinkError: Native library (com/sun/jna/z/os-s390/libjnidispatch.so) not found in resource path (Ýfile:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/,
    file:/ST/usr/lpp/java/IBM/J8.0/lib/, file:/ST/usr/lpp/java/IBM/J8.0/lib/ext/,
    file:/ST/usr/lpp/java/json/org.json-20120521.jar,
    file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/CDRMigrateAccumsToAtlas.jar,
    file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/bson-4.2.3.jar,
    file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/jna-5.6.0.jar,
    file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/json-20160810.jar,
    file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/logback-classic-1.2.3.jar,
    file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/logback-core-1.2.3.jar,
    file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/mongodb-crypt-1.2.0.jar,
    file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/mongodb-driver-core-4.2.3.jar,
    file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/mongodb-driver-sync-4.2.3.jar,
    file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/recordio.jar,
    file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/slf4j-api-1.7.6.jar,
    file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/vault-java-driver-5.1.0.jar,
    file:/sharedappdev/test/CD/apps/mongopoc/mongo40apps/*.mar¨)
    at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1032)
    at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:988)
    at com.sun.jna.Native.<clinit>(Native.java:195)

    Please modify your drivers so our java applications can encrypt and decrypt from the mainframe (zOS) UNIX environment. This missing feature is a road-block to our migration to Atlas.

    We have multiple Java applications that run on an IBM mainframe. Those applications read and write into MongoDB collections, like inserting Mainframe data into MongoDB collections. The mongo-crypt driver for CSFLE does not work on the Mainframe UNIX environment.

    Company policy states we have to encrypt all PHI/PII data prior to inserting the data into Atlas.

    I had opened a support ticket with MongoDB and the final reply was you do… more

    7 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

    under review  ·  0 comments  ·  Java  ·  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. Go Driver: Allow Client Side Field Level Encryption (CSFLE) to use IAM Role credentials credentials with KMS access

    In order to get the MongoDB csfle lib to work with AWS KMS, we need to set
    the following provider details (IAM user credentials) explicitly: accessKeyId and secretAccessKey.

    It is common and more secure practice for applications to be able to get temporary credentials using IAM roles which will have accessKeyId, secretAccessKey and sessionToken - https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html.

    Currently, the Go Driver does not support sending 'sessionToken' along with provider details.

    The libmongocrypt library has this support now - https://github.com/mongodb/libmongocrypt/pull/153.

    It would be great if Go driver has this support.

    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  ·  Go  ·  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. GeoNear support on C# driver

    Would be great to have GeoNear support on csharp driver https://docs.mongodb.com/manual/reference/operator/aggregation/geoNear/

    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  ·  C#  ·  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. Support "default" keyword in MongoDB's implementation of JSON Schema

    Without defaults, there is a need to iterate though each property just to check if a default value is needed (most probably this can be easily done on type check). Also without defaults we need to remember checking it both in inserts and updates (for example with $push operator)

    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  ·  Node.js  ·  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 some casting addon or function based on MongoDB's implementation of JSON Schema

    Without casting addons, there is a need to iterate though each property just to check if this value needs some casting (most probably this can be easily done on type check). I´m having special troubles with Date type, as most of the time this type is send as an ISO string, but saved in the DB as a DATE

    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  ·  Node.js  ·  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. Compressed Fields

    When large JSON structures are being stored but don't need to be queryable it may be more performant to handle the compression at the field-level as opposed to the network level (similar to what is described in https://medium.com/idealo-tech-blog/advanced-mongodb-performance-tuning-2ddcd01a27d2).

    This would isolate compression and decompression on the client side (unless network compression was used as well), however the compressed field would be persisted as-is (compressed) to the cluster.

    5 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Unspecified  ·  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. Short-lived AWS EKS token

    Native support for short-lived AWS EKS token in MongoDB java driver, with the ability to refresh the key without any application downtime.

    3 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Java  ·  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. Dynamic Configuration Changes for Connections

    We would like to suggest a feature improvement where connection parameters can be dynamically changed so that no restart of client application infrastructure is needed.

    Currently, when changing connection configuration, this usually requires the restart of a considerable number of pods or containers with the unavoidable consequence of a sudden surge in connection attempts.

    Our request specifically would be to provide a way for drivers to read both connection string and connection parameters information from a source that can be easily managed and that's not necessarily embedded in the code, and

    Drivers should also detect when this configuration has changed and gradually refresh connections to reflect the new configuration. Ideally there would be ways of forcing the driver to be more aggressive or more gradual, which should accommodate for emergency situations or tuning scenarios that are not urgent. This is the part that would avoid any client infrastructure restart, and avoid sudden surges in connection attempts.

    We would like to suggest a feature improvement where connection parameters can be dynamically changed so that no restart of client application infrastructure is needed.

    Currently, when changing connection configuration, this usually requires the restart of a considerable number of pods or containers with the unavoidable consequence of a sudden surge in connection attempts.

    Our request specifically would be to provide a way for drivers to read both connection string and connection parameters information from a source that can be easily managed and that's not necessarily embedded in the code, and

    Drivers should also detect when this configuration has changed… more

    3 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Unspecified  ·  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. Provide a direct download for current versions of driver files/dependencies on the official MongoDB sites

    Note: This post was inspired by my attempts to find a direct download for the MongoDB Java driver, but I've left the category as "Unspecified" because it could apply to any driver download for which the official sites say to "Just use Maven/etc"

    Right now the documentation for the MongoDB Java driver (https://mongodb.github.io/mongo-java-driver/4.2/driver/getting-started/installation/) indicates that "The recommended way to get started using one of the drivers in your project is with a dependency management system." However, as far as I could tell from my own research, the official MongoDB sites have no official direct download link for the driver/dependency jar files - only the Maven groupId/artifactId are provided. If for some reason a developer is restricted such that they cannot use a dependency manager for their project and must obtain the jar files as a direct download, they must find the official Apache Maven repository on their own, and download the files from there.

    I understand that this seems like a problem that can be solved by saying "just suck it up and use Maven", but please understand that at its core, this actually constitutes a security issue, as it makes it difficult for developers to find a download that they know they can trust.

    Consider the following situation: Due to some situation, a developer is unable to use a dependency manager for their project. They must use a direct download of the driver/dependency jar files for the MongoDB Java driver in order to do their job. The first thing they will likely do (rightfully so) is go to the official MongoDB sites to try and find a download. They will not find it, and will instead look elsewhere.

    Performing a Google search for "mongodb java driver" returns first the official MongoDB sites, which the developer already knows will not help them, and then returns an unofficial Maven Repository browser (mvnrepository). I haven't looked into the validity of this site, and I'm usually one to assume the best of intentions, but the fact remains that it's run by a person who is not affiliated with Apache/Maven or MongoDB, from which the developer will likely download several unverified jar files and include them with their project. This is a big security risk, as theoretically speaking, for all we know this site could be malicious, but it remains the most convenient option for the developer, because the official MongoDB sites do not include one. The safest option for the developer is to use the official Maven repository at search.maven.org, but this site only appears at the very bottom of the first page of the Google results, and the developer may not even see this during their search.

    I feel like this problem could be fully solved by creating a section on the "Downloads" page (https://www.mongodb.com/try/download) for drivers, and including the most recent normally-supported release of each driver, including its dependencies. This may not be the recommended method, and it could very well include prominent text encouraging developers to consider using a dependency manager if possible, but it would effectively remove the potential for developers to accidentally download a malicious jar file from an unverified source and include it with their project.

    TL;DR: If you don't include a direct downloads for MongoDB drivers/dependencies, a malicious actor on the internet will.

    Note: This post was inspired by my attempts to find a direct download for the MongoDB Java driver, but I've left the category as "Unspecified" because it could apply to any driver download for which the official sites say to "Just use Maven/etc"

    Right now the documentation for the MongoDB Java driver (https://mongodb.github.io/mongo-java-driver/4.2/driver/getting-started/installation/) indicates that "The recommended way to get started using one of the drivers in your project is with a dependency management system." However, as far as I could tell from my own research, the official MongoDB sites have no official direct download link for 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  ·  Unspecified  ·  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