datagrip / mongo-jdbc-driver Goto Github PK

View Code? Open in Web Editor NEW

52.0 9.0 11.0 70.08 MB

This driver is embedded to DataGrip

License: Apache License 2.0

Java 91.99% JavaScript 8.01%

mongo-jdbc-driver's Introduction

MongoDb JDBC Driver

This is an open source JDBC Driver for MongoDb.

To build a standalone jar:

./gradlew shadowJar

mongo-jdbc-driver's People

Contributors

Stargazers

Watchers

Forkers

tsegall rodolfoap kanghoonyi greatdennis hangum lizen dijp spencerswagger mnloveyx maple-mxf santugege

mongo-jdbc-driver's Issues

When to support ISODate format 'YYmmdd'?

it's wired that not support 'YYmmdd' format,although support YY-mm-dd now,can make a little step forward?

Method db.collection.distinct is not implemented.

Hi, I'm using DataGrip with mongodb driver and faced error

Method db.collection.distinct is not implemented.

And found out it's really not implemented.
https://github.com/DataGrip/mongo-jdbc-driver/blob/master/src/main/java/com/dbschema/mongo/nashorn/JMongoCollection.java#L66

Is there any plan to support this? and why doesn't it work?

I wish i could run it in java 1.8.

I wish I could run it in JAVA 1.8.

Man underlying libraries still work with Java 1.8.
I hope it is compatible with 1.8.

Thanks.

Maven Dependency missing from maven central repo

Trying to setup flyway with mongo using maven

https://documentation.red-gate.com/flyway/flyway-cli-and-api/supported-databases/mongodb

But not able to find the jar:

com.github.kornilova203
mongo-jdbc-driver
1.19

I tried to find out it in maven central repository, But didnt find.

Expected: Dependency should be present in maven central repo: https://repo1.maven.org/maven2/com/github/

Unable to connect with x509v3 certificate

Currently unable to connect to a mongo database using a tlsCaCert and I'm getting the following message in the logs.

2022-06-10 10:34:28,302 [348430195]   INFO - #c.i.e.r.RemoteProcessSupport - Port/ServicesPort/ID: 26991/65365/RemoteDriverImpl6de0821f
2022-06-10 10:34:28,302 [348430195]   INFO - #c.i.e.r.RemoteProcessSupport - 
2022-06-10 10:34:28,302 [348430195]   INFO - #c.i.e.r.RemoteProcessSupport - 
2022-06-10 10:34:28,337 [348430230]   INFO - #c.i.d.d.DatabaseConnectionEstablisher - Connecting to: mongodb://dbhost.com:27017/?authSource=admin&tlsAllowInvalidCertificates=true
2022-06-10 10:34:28,339 [348430232]   INFO - #c.i.d.d.DatabaseConnectionEstablisher - Auth provider: user-pass
2022-06-10 10:34:28,345 [348430238]   INFO - #c.i.d.d.DatabaseCredentialsAuthProvider - Connecting as: dbuser
2022-06-10 10:34:28,406 [348430299]   INFO - #c.i.e.r.RemoteProcessSupport - SSL MODE is REQUIRE
2022-06-10 10:34:28,406 [348430299]   INFO - #c.i.e.r.RemoteProcessSupport - setting driver log level to ALL
2022-06-10 10:34:28,406 [348430299]   INFO - #c.i.e.r.RemoteProcessSupport - setting driver log path to null
2022-06-10 10:34:28,406 [348430299]   INFO - #c.i.e.r.RemoteProcessSupport - DriverManager.LogWriter.level=ALL
2022-06-10 10:34:28,406 [348430299]   INFO - #c.i.e.r.RemoteProcessSupport - com.dbschema.level=ALL
2022-06-10 10:34:28,416 [348430309]   WARN - #c.i.e.r.RemoteProcessSupport - WARNING: password was automatically url-encoded. To turn it off set auto_encode_username_and_password driver property to false.
2022-06-10 10:34:28,449 [348430342]   WARN - #c.i.e.r.RemoteProcessSupport - Jun 10, 2022 5:34:28 PM com.mongodb.diagnostics.logging.Loggers shouldUseSLF4J
2022-06-10 10:34:28,449 [348430342]   WARN - #c.i.e.r.RemoteProcessSupport - WARNING: SLF4J not found on the classpath.  Logging is disabled for the 'org.mongodb.driver' component
2022-06-10 10:34:28,626 [348430519]   INFO - #c.i.e.r.RemoteProcessSupport - Driver: MongoDB JDBC Driver 1.13
2022-06-10 10:34:38,640 [348440533]   INFO - #c.i.e.r.RemoteProcessSupport - getDatabaseProductName: Mongo DB
2022-06-10 10:34:50,353 [348452246]   INFO - #c.i.c.ComponentStoreImpl - Saving appCodeFoldingSettings took 15 ms
2022-06-10 10:35:13,035 [348474928]   WARN - #c.i.e.r.RemoteProcessSupport - DBMS detection failed
2022-06-10 10:35:13,036 [348474929]   WARN - #c.i.e.r.RemoteProcessSupport - java.sql.SQLException: com.mongodb.MongoTimeoutException: Timed out after 10000 ms while waiting to connect. Client view of cluster state is {type=UNKNOWN, servers=[{address=dbhost.com:27017, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketWriteException: Exception sending message}, caused by {javax.net.ssl.SSLHandshakeException: Failed to parse server certificates}, caused by {java.security.cert.CertificateParsingException: no more data allowed for version 1 certificate}}]
2022-06-10 10:35:13,036 [348474929]   WARN - #c.i.e.r.RemoteProcessSupport - at com.dbschema.mongo.mongosh.MongoshScriptEngine.execute(MongoshScriptEngine.java:74)
2022-06-10 10:35:13,036 [348474929]   WARN - #c.i.e.r.RemoteProcessSupport - at com.dbschema.mongo.MongoPreparedStatement.executeQuery(MongoPreparedStatement.java:55)
2022-06-10 10:35:13,036 [348474929]   WARN - #c.i.e.r.RemoteProcessSupport - at com.dbschema.mongo.MongoPreparedStatement.execute(MongoPreparedStatement.java:61)
2022-06-10 10:35:13,036 [348474929]   WARN - #c.i.e.r.RemoteProcessSupport - at com.dbschema.mongo.MongoPreparedStatement.execute(MongoPreparedStatement.java:479)

I have confirmed my credentials and tlsCaCert work using the mongosh and mongodb-compass clients.

$ mongo \
  ...
		--ssl \
		--sslCAFile x509v3file.crt \
		--sslAllowInvalidHostnames \
		--sslAllowInvalidCertificates \
		...

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: ...
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: ...
        Validity
            Not Before: Oct 14 21:59:48 2016 GMT
            Not After : Oct 12 21:59:48 2026 GMT
        ...
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    ...
                Exponent: ...
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                ...
            X509v3 Authority Key Identifier:
                ...
            X509v3 Basic Constraints:
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption

CVE-2022-42889 at Apache Commons Text 1.8 over

CVE-2022-42889

mote servers if untrusted configuration values are used. Users are recommended to upgrade to Apache Commons Text 1.10.0

Please support java 1.8 as well.

Many applications are using Java 1.8.
It well be very helpful if you apply for 1.8.

java.lang.IllegalArgumentException: Could not find option with name engine.WarnInterpreterOnly.

because my jdk version is 1.8. So I changed the org.graalvm.sdk:graal-sdk version to 20.2.0. And has changed Engine.create("js") to Engine.create(). and then when I new a MongoJdbcDriver, I got the exception.
java.lang.IllegalArgumentException: Could not find option with name engine.WarnInterpreterOnly.

If you have time to answer, thank you very much

Aggregation -> projected fields are not returned in specified order in DataGrip

It's an issue in DataGrip, the query works well in mongosh 1.5.0.

Test Data:

Suppose I a collection for test like this, in which the fields are _id, address, id:

Note field address goes before field id.

Query:

db.testaa.aggregate([
{
    $project: {
        _id: "$_id",
        id: "$id",
        address: "$address",
}
}]);

The Problem:

The query is to project fields and expect the field id goes before field address. it works well in Mongosh 1.5.0 but not work in DataGrip (2021.3.1, with driver ver. 1.15, JDBC4.2). In DataGrip, it returns the correct fields values but in default order, instead of the specified order in project expression.

Array handling is not working as it should in `$or` and `$in`

In IntelliJ with driver version 1.7.3, the following query executes on mongo shell, but fails in IntelliJ

db.pages.find({
    $or: [
        {'page.tag': {$in: ['a', 'b', 'c']}}
    ]
});

With error code 2 and error message $in needs an array.

Let me know if you need any more info :)

Implement collection.deleteMany in ui view

I would like to suggest implementing the deleteMany function if you delete more than one document via the ui collection view.

If you currently wish to delete more than one document, Datagrip will go through every single document and call deleteOne on it. It would be more efficient to use deleteMany one time and delete every single document selected. An example deleteMany command would be:

db.getCollection("testCollection").deleteMany({ $or: [ {
   _id: new ObjectId("6220db3d9362dd2bc1a86096"),
   _id: new ObjectId("6220db409362dd2bc1a860c5")
 } ] } );

Datagrip would just need to get all the _id fields of the selected documents and call the deleteMany method once. It currently takes about 45s to delete 100 documents, and this could be very much decreased by deleting all at once.

The official JDBC driver for mongoDb has come out, version 1.0.0,has plan to integrated ?

The official JDBC driver for mongoDb has come out, version 1.0.0, is there any consideration for integrated use?

How can i data?

MongoDB version : 3.4.6
MongoDB Driver ver: 1.6 or master branch

The module_map collection has data.

Howerer, if you run the following sources, there is no data.
Test source:

`
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.ResultSetMetaData;
import java.sql.Statement;

import com.mongodb.DBCollection;

public class MongoDBTest {
public static void main(String[] args) {
System.out.println("===== starting test... source of github");
String url = "mongodb://root:[email protected]:32769/admin";

    try {
        Class.forName("com.dbschema.MongoJdbcDriver");
        Connection con = DriverManager.getConnection(url, null, null);
        con.setCatalog("test2");
        Statement stmt=con.createStatement();
        ResultSet rs = stmt.executeQuery("db.module_map.find()");//db.getCollection('dbtype').find({})");//db.module_map.find()");//"db.getCollection('system.users').find({})");
        
        ResultSetMetaData rsm = rs.getMetaData();
        System.out.println("\t column count: " + rsm.getColumnCount());
        System.out.println("\t column name is " + rsm.getColumnDisplaySize(1));
        
        System.out.println("\t get row is " + rs.getRow());
        
        while(rs.next()) {
            Object obj = rs.getObject(0);
            if(obj instanceof DBCollection) {
                System.out.println("\t dbcollection");
            } else {
                System.out.println("\t" + obj.getClass().getName());
            }
            System.out.println("==> " + obj.toString());
        }

    } catch(Exception e) {
        e.printStackTrace();
    }
    
    System.out.println("====== end test");
}

}
`
result:

thanks.

MongoDB connection is not close.

Using the database and close the connection does not close.
Please check.

As shown below, I turned 10 threads and ended all.
10 deamon thread are alive.

Example source.
`public class MongoDBTest implements Runnable {
public static void main(String[] args) {
for(int i=0; i<10; i++) new Thread(new MongoDBTest()).start();
}

@Override
public void run() {
	System.out.println("===== starting test...  source of github");
	String url = "mongodb://[email protected]:32769/admin";

	Connection con = null;
	Statement stmt = null;
	ResultSet rs = null;
    try {
        Class.forName("com.dbschema.MongoJdbcDriver");
        con = DriverManager.getConnection(url, null, null);
        con.setSchema("test2");
        stmt = con.createStatement();
        rs = stmt.executeQuery("db.getCollection('dbtype').find({})");//db.module_map.find()");//"db.getCollection('system.users').find({})");
        
        ResultSetMetaData rsm = rs.getMetaData();
        System.out.println("\t column count: " + rsm.getColumnCount());
        System.out.println("\t column name is " + rsm.getColumnDisplaySize(1));
        System.out.println("\t get row is " + rs.getRow());
        
        System.out.println("\t table name is " + rsm.getTableName(1));

        while(rs.next()) {
            Object obj = rs.getObject(1);
            if(obj instanceof DBCollection) {
                System.out.println("\t dbcollection");
            } else {
                System.out.println("\t" + obj.getClass().getName());
            }
            System.out.println("==> " + obj.toString());
        }

    } catch(Exception e) {
        e.printStackTrace();
    } finally {
    	try { if(rs != null) rs.close(); } catch(Exception e) {e.printStackTrace();}
    	try { if(stmt != null) stmt.close(); } catch(Exception e) {e.printStackTrace();}
    	try { if(con != null) con.close(); } catch(Exception e) {e.printStackTrace();}
    }
    
    System.out.println("====== end test");
}

}
`

StackOverflowError when using conflicting GraalVM

I am getting a red snackbar in both the table tab and the query console tab. It says "java.lang.StackOverflowError" and no data loads.

This error does not occur with the provided JetBrains Runtime. The table and queries work fine when it is being used. Reverting to it is a workaround. I know switching the JDK is not officially supported, but JBR is way too slow. I am using GraalVM 22.3.0 Java 19 with "gu install js" and several performance-tuning VM options.

It appears that the GraalVM in the Jar is conflicting with the one I'm trying to use.

2022-11-18 21:11:54,004 [  22258]   WARN - #c.i.d.d.BaseDatabaseErrorHandler$UnknownErrorInfo - Error occurred in server thread; nested exception is: 
        java.lang.StackOverflowError
java.rmi.ServerError: Error occurred in server thread; nested exception is: 
        java.lang.StackOverflowError
        at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:389)
        at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
        at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
        at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:598)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:844)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:721)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:720)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
        at java.base/java.lang.Thread.run(Thread.java:1589)
        at java.rmi/sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:304)
        at java.rmi/sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:280)
        at java.rmi/sun.rmi.server.UnicastRef.invoke(UnicastRef.java:166)
        at java.rmi/java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:215)
        at java.rmi/java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:160)
        at jdk.proxy6/jdk.proxy6.$Proxy235.execute(Unknown Source)
        at com.intellij.database.dataSource.connection.statements.StandardExecutionMode$GENERIC.execute(StandardExecutionMode.kt:10)
        at com.intellij.database.dataSource.connection.statements.JdbcBasedSmartStatement$Simple.executeJdbcStatement(JdbcBasedSmartStatement.kt:259)
        at com.intellij.database.dataSource.connection.statements.JdbcBasedSmartStatement$Simple.executeJdbcStatement(JdbcBasedSmartStatement.kt:252)
        at com.intellij.database.dataSource.connection.statements.JdbcBasedSmartStatement$memorizeAndExecute$1$1.invoke(JdbcBasedSmartStatement.kt:86)
        at com.intellij.database.dataSource.connection.statements.JdbcBasedSmartStatement$memorizeAndExecute$1$1.invoke(JdbcBasedSmartStatement.kt:22)
        at com.intellij.database.dataSource.connection.statements.SmartStatementsUtil.runReporting(SmartStatementsUtil.kt:82)
        at com.intellij.database.dataSource.connection.statements.JdbcBasedSmartStatement$memorizeAndExecute$1.invoke(JdbcBasedSmartStatement.kt:85)
        at com.intellij.database.dataSource.connection.statements.JdbcBasedSmartStatement$memorizeAndExecute$1.invoke(JdbcBasedSmartStatement.kt:22)
        at com.intellij.database.dataSource.connection.Either.transform(Either.kt:23)
        at com.intellij.database.dataSource.connection.EitherKt.transformSafe(Either.kt:45)
        at com.intellij.database.dataSource.connection.statements.JdbcBasedSmartStatement.memorizeAndExecute(JdbcBasedSmartStatement.kt:84)
        at com.intellij.database.dataSource.connection.statements.JdbcBasedSmartStatement.access$memorizeAndExecute(JdbcBasedSmartStatement.kt:22)
        at com.intellij.database.dataSource.connection.statements.JdbcBasedSmartStatement$executeInCommonWay$1.invoke(JdbcBasedSmartStatement.kt:72)
        at com.intellij.database.dataSource.connection.statements.JdbcBasedSmartStatement$executeInCommonWay$1.invoke(JdbcBasedSmartStatement.kt:22)
        at com.intellij.database.dataSource.connection.Either.transform(Either.kt:23)
        at com.intellij.database.dataSource.connection.EitherKt.transformSafe(Either.kt:45)
        at com.intellij.database.dataSource.connection.statements.JdbcBasedSmartStatement.executeInCommonWay(JdbcBasedSmartStatement.kt:71)
        at com.intellij.database.dataSource.connection.statements.JdbcBasedSmartStatement.execute(JdbcBasedSmartStatement.kt:46)
        at com.intellij.database.dataSource.connection.statements.NoisyStatement.execute(NoisyStatement.kt:24)
        at com.intellij.database.console.JdbcEngine$RegularExecutor.execute(JdbcEngine.java:1403)
        at com.intellij.database.console.JdbcEngine$QueryExecutionOperation.lambda$execute$1(JdbcEngine.java:1991)
        at com.intellij.database.dialects.base.BaseExecutionEnvironmentHelper.runInSpecificEnvironment(BaseExecutionEnvironmentHelper.java:107)
        at com.intellij.database.console.JdbcEngine$QueryExecutionOperation.execute(JdbcEngine.java:1990)
        at com.intellij.database.console.JdbcEngine$QueryExecutionOperation.perform(JdbcEngine.java:1935)
        at com.intellij.database.console.JdbcEngine$OperationBase.perform(JdbcEngine.java:1602)
        at com.intellij.database.console.JdbcEngine.lambda$visitQuery$4(JdbcEngine.java:419)
        at com.intellij.database.console.JdbcEngine.lambda$submitRequest$16(JdbcEngine.java:1095)
        at com.intellij.database.console.AbstractEngine.lambda$submitRequest$8(AbstractEngine.java:238)
        at com.intellij.database.console.AbstractEngine.lambda$submitRunnable$6(AbstractEngine.java:209)
        at com.intellij.database.util.AsyncTask$Frame$sync$$inlined$framed$intellij_database_core_impl$1.run(AsyncTask.kt:507)
        at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$12(CoreProgressManager.java:608)
        at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:683)
        at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:639)
        at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:607)
        at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:60)
        at com.intellij.database.util.AsyncTask$Frame.sync(AsyncTask.kt:532)
        at com.intellij.database.console.AbstractEngine.lambda$submitRunnable$7(AbstractEngine.java:207)
        at com.intellij.database.console.AbstractEngine.lambda$submitRunnable$5(AbstractEngine.java:188)
        at com.intellij.database.util.AsyncTask$Frame$compute$$inlined$supply$1$1.run(AsyncTask.kt:507)
        at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$12(CoreProgressManager.java:608)
        at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:623)
        at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:607)
        at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:60)
        at com.intellij.database.util.AsyncTask$Frame$compute$$inlined$supply$1.get(AsyncTask.kt:532)
        at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
        at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: java.lang.StackOverflowError
        at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.GraalTruffleRuntimeListenerDispatcher.onCompilationDeoptimized(GraalTruffleRuntimeListenerDispatcher.java:110)
        at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.notifyDeoptimized(OptimizedCallTarget.java:730)
        at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.executeRootNode(OptimizedCallTarget.java:720)
        at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.profiledPERoot(OptimizedCallTarget.java:632)
        at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.doInvoke(OptimizedCallTarget.java:549)
        at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.GraalRuntimeSupport.callProfiled(GraalRuntimeSupport.java:256)
        at org.graalvm.truffle/com.oracle.truffle.polyglot.PolyglotValueDispatch$InteropValue.execute(PolyglotValueDispatch.java:2396)
        at org.graalvm.sdk/org.graalvm.polyglot.Value.execute(Value.java:880)
        at com.mongodb.mongosh.ValueWrapper.isWrapped(ValueWrapper.kt:33)
        at com.mongodb.mongosh.MongoShellConverter.toJava(MongoShellConverter.kt:131)
        at com.mongodb.mongosh.MongoShellConverter.toJava$default(MongoShellConverter.kt:129)
(then the last two lines keep repeating)

Can you make this driver compatible with the performant GraalVM 22.3 please?

Update java shell version to support MONGO-AWS auth mechanism (MongoDB version >=4.4)

Hey there--
Our team wants to use datagrip to interact with a mongo atlas database using the authentication mechanism described here: https://docs.mongodb.com/drivers/node/fundamentals/authentication/mechanisms#mongodb-aws, which is only supported by MongoDB version >= 4.4, which I gather means shell version >=4.4 as well.

It looks like mongosh (https://github.com/mongodb-js/mongosh) supports this feature, with the added requirement of aws4 (https://www.npmjs.com/package/aws4), but I can see that the forked version of mongosh, (https://github.com/kornilova203/mongosh) is stuck at v0.3, whereas the original is up to 0.7.7 https://github.com/mongodb-js/mongosh/releases/tag/v0.7.7 Is there any chance of using the original version to back this driver, or updating the fork any time soon?

User management method does not work.

These are the instructions below.
https://docs.mongodb.com/manual/reference/method/js-user-management/
thanks.

Name | Description
db.auth() | Authenticates a user to a database.
db.changeUserPassword() | Changes an existing user’s password.
db.createUser() | Creates a new user.
db.dropUser() | Removes a single user.
db.dropAllUsers() | Deletes all users associated with a database.
db.getUser() | Returns information about the specified user.
db.getUsers() | Returns information about all users associated with a database.
db.grantRolesToUser() | Grants a role and its privileges to a user.
db.removeUser() | Deprecated. Removes a user from a database.
db.revokeRolesFromUser() | Removes a role from a user.
db.updateUser() | Updates user data.
passwordPrompt() | Prompts for the password as an alternative to specifying passwords directly in various mongo shell user authentication/management methods.

Test connection too slow

I'm using the newest Datagrip with the newest Mongo driver v1.12.
But it's too slow when test connection / open a connection to query, it took great than 17s :(
And it's the same when execute a simple query (find with limit 10 item) on a collection >10s :(

I checked Mongo driver other versions and summary in here (test connection - query time):

v1.12: >17s - >10s
v1.8 - v1.11: >5s - >2s
<=v1.73: >2s - >2s

Could you @kornilova203 please check this issue and give me some advices?

There is no pattern support for schemas/tables as per the JDBC specification

I have added a PR (#9) and was wondering whether you would consider merging it.

How to connect MongoDb verison less than 2.6?

MongoshScriptEngine execute result instanceof xxxResult always return null

MongoshScriptEngine execute result instanceof xxxResult return null
Why is it null? It actually has results in mongosh.

I changed it so that it can always return the result.

  if (result instanceof VoidResult || result instanceof MongoShellUpdateResult || result instanceof BSONTimestampResult){
    return Util.ok(result._asPrintable());
  }else if (result instanceof DateResult || result instanceof DBRefResult || result instanceof InsertOneResult
          || result instanceof UUIDResult){
    return Util.ok(result.getValue().toString());
  }else {
    return Util.ok(result.getValue());
  }

java.lang.Exception: SyntaxError: Private names are only allowed in property accesses (`obj.#mongo`) or in `in` expressions (`#mongo in obj`). (1:0)

> 1 | #mongo 
    | ^
  2 |
  3 | db.getCollection('d0eaf6d6c0baeb08e0d8f080c412c656_59bf52eaeb1a48d3b51c2729fe3b62e6_base').remove({
  4 |  process_instance_id: {
    at Parser._raise (all-standalone.js:734:17451)
    at Parser.raiseWithData (all-standalone.js:734:17390)
    at Parser.raise (all-standalone.js:734:16855)
    at Parser.parseExprOp (all-standalone.js:734:211059)
    at Parser.parseExprOps (all-standalone.js:734:210878)
    at Parser.parseMaybeConditional (all-standalone.js:734:210282)
    at Parser.parseMaybeAssign (all-standalone.js:734:209608)
    at Parser.parseExpressionBase (all-standalone.js:734:208738)
    at all-standalone.js:734:208637
    at Parser.allowInAnd (all-standalone.js:734:241873)

Unsupported projection option

db.getCollection("col").find({}, {
"e": "$empNo",
"b":{
$switch: {
branches: [
{
case: {
$eq: ["$a", "1"]
},
then: "1-a"
},
{
case: {
$eq: ["$a", "2"]
},
then: "1-b"
},
],
default: ""
}
}
});

com.mongodb.MongoQueryException: Query failed with error code 2 with name 'BadValue' and error message 'Unsupported projection option: b: { $switch: { branches: [ { case: { $eq: [ "$a", "1" ] }, then: "1-a" }, { case: { $eq: [ "$a", "2" ] }, then: "1-b" } ], default: "" } }' on server

Jar files have incorrect location for java.sql.Driver

The jar files created by the build script have java.sql.Driver in the jar/META-INF/services directory. As per the JDBC 4.2 specification (https://download.oracle.com/otn-pub/jcp/jdbc-4_2-mrel2-spec/jdbc4.2-fr-spec.pdf?AuthParam=1592503219_c759451c5b8cba86fa4a5e42f2c84cc6) section 9.2.1 Loading a driver that implements java.sql.Driver

"JDBC 4.0 Drivers must include the file META-INF/services/java.sql.Driver. "

So this file should be in META-INF/services/java.sql.Driver and not jar/META-INF/services .

As it stands we need to unjar the archive, move the files, and then rejar to use this driver.

Thoughts?

Is there any example use this driver as jdbc from java/kotlin code?

Some like this:

Class.forName("mongodb.jdbc.MongoDriver");
DriverManager.getConnection("jdbc:mongodb://server:27017/blabase")