Mongosh does not work as expected in several cases

I do not understand what’s going on. I never had these issues before. I encountered this behaviour in both the latest 6.x version as well as on 4.2.X (which we use now as we want to use Azure Cosmos DB later on).

I was buffled when I tried to use the following snippet to test our microframework we’re currently building (using the .NET Driver):

db.Books.updateMany({}, {$set: {'newField': true}})

This occurs in both MongoDB Compass as well as DataGrip, both connected to my test database “Test”. This has one collection called “Books” with 10 documents I generated using my test application.

This command does not match any document (which makes no sense since I am using an empty filter), while when I execute the same thing using the .NET driver the field is inserted into all 10 documents.

Now I needed to create a new collection. So I used:


Which should obviously create a collection called “Books2” in my Test database. But all Mongo returns is the following exception:

MongoServerError: db already exists with different case already have: [Test] trying to create [test]
    at Connection.onMessage (C:\Users\eisen\AppData\Local\MongoDBCompass\app-1.35.0\resources\app.asar.unpacked\node_modules\@mongosh\node-runtime-worker-thread\dist\worker-runtime.js:1917:3099431)
    at MessageStream.<anonymous> (C:\Users\eisen\AppData\Local\MongoDBCompass\app-1.35.0\resources\app.asar.unpacked\node_modules\@mongosh\node-runtime-worker-thread\dist\worker-runtime.js:1917:3096954)
    at MessageStream.emit (node:events:394:28)
    at c (C:\Users\eisen\AppData\Local\MongoDBCompass\app-1.35.0\resources\app.asar.unpacked\node_modules\@mongosh\node-runtime-worker-thread\dist\worker-runtime.js:1917:3118818)
    at MessageStream._write (C:\Users\eisen\AppData\Local\MongoDBCompass\app-1.35.0\resources\app.asar.unpacked\node_modules\@mongosh\node-runtime-worker-thread\dist\worker-runtime.js:1917:3117466)
    at writeOrBuffer (node:internal/streams/writable:389:12)
    at _write (node:internal/streams/writable:330:10)
    at MessageStream.Writable.write (node:internal/streams/writable:334:10)
    at Socket.ondata (node:internal/streams/readable:749:22)
    at Socket.emit (node:events:394:28)

Why? I clearly am operating ON my databse and try to create a collection as the method name states. Why is it trying to create a new database when I run this command?

Something is awfully off with mongosh. I don’t know why, but so far no command worked as expected while running these via the driver worked just fine.

Can somebody explain me what’s going on? If this is it, we might have to consider seriously moving to a different database system.

Most likely you have upper case vs lower case issue.

The error strongly point to what is your error.

Your collection Books probably exists in the database Test with an the first letter being an uppercase T. You most likely run the command use test with a leading lowercase t, (or used a connection string that specify test with lowercase t. Since Books exists in the database Test, no documents exists in the database test. For some technical reasons, file names in Windows are not case sensitive, you cannot create the collection test.Books2 because the database Test already exists. Exactly as mentioned in the error message.

1 Like

Thanks, that seems to be the issue. I never noticed that the shell said “test”. I just figured this should be sufficient. When explicitly switching to “Test” it works like a charm. I don’t get why Compass and DataGrip use the right database name but in wrong casing as default then…

1 Like

I do not know about DataGrip but it seems Compass respect the case of the default database specified on the URI.

If my URI ends with /Foobar the db variable of the shell is set to Foobar. If it ends with /foobar it db is equal to foobar.

I see no option to configure this in MongoDB Compass. Only database you can define is the authentication database and that’s something different. But at least I now know what to do…

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.