Amazon DocumentDB: Cannot create any record with prisma `ConnectorError`

Bug description

Currently we’ve been trying to set up a mongo with a document DB cluster in AWS to use with Prisma, however we couldn’t even make a simple CRUD work.

Any time prisma tries to execute a query that inserts data on the mongo cluster, it crashes with the following message: ConnectorError(ConnectorError { user_facing_error: None, kind: RawDatabaseError { code: "unknown", message: "Command failed (): Feature not supported)" } })

I have no clue on what the problem is, we’ve followed the instructions in the docs to set up the application configuration.

Note that, prisma can read the data normally, the problem only occurs when inserting data.

We know that the database is correclty configured because we tried two other ORMs everything worked.

Maybe Prisma does not support AWS Document Db? wich is weird since it uses Mongo under the hood, right?

How to reproduce

1- Configure a Document Db on AWS 2 - Set up the schema.prisma 3 - Try to insert any data using prisma.model.create() I’m sorry I can’t provide any more details to reproduce, it was our infrastructure team that setted the databases up for us devs to work with, we requested a mongoDb configured with a replica set to use with Prisma and they gave us back the credentials 😛

Expected behavior

The client should be able to connect to a mongoDb cluster on AWS and perform all available operations within PrismaClient

Prisma information

// schema.prisma
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "mongodb"
  url      = env("DATABASE_URL")
}

model Users {
  id        String @id @default(auto()) @map("_id") @db.ObjectId
  name      String
}

// .env 
DATABASE_URL=mongodb://user:password@host:port/database?authSource=admin&readPreference=primary&directConnection=true&ssl=false&retrywrites=false

Environment & setup

• OS: Windows–>
• Database: MongoDb–>
• Node.js version: 16.1–>

Prisma Version

prisma                  : 3.13.0
@prisma/client          : 3.13.0
Current platform        : windows
Query Engine (Node-API) : libquery-engine efdf9b1183dddfd4258cd181a72125755215ab7b (at node_modules\@prisma\engines\query_engine-windows.dll.node)
Migration Engine        : migration-engine-cli efdf9b1183dddfd4258cd181a72125755215ab7b (at node_modules\@prisma\engines\migration-engine-windows.exe)
Introspection Engine    : introspection-core efdf9b1183dddfd4258cd181a72125755215ab7b (at node_modules\@prisma\engines\introspection-engine-windows.exe)
Format Binary           : prisma-fmt efdf9b1183dddfd4258cd181a72125755215ab7b (at node_modules\@prisma\engines\prisma-fmt-windows.exe)
Default Engines Hash    : efdf9b1183dddfd4258cd181a72125755215ab7b
Studio                  : 0.459.0

[janpio]

Quoting Wikipedia:

Amazon DocumentDB is a managed proprietary NoSQL database service that supports document data structures and has limited support for MongoDB workloads, with some compatibility with MongoDB version 3.6 (released by MongoDB in 2017) and version 4.0 (released by MongoDB in 2018).

Note that Prisma support MongoDB 4.2+ - so this not working is not unexpected.

https://www.mongodb.com/atlas-vs-amazon-documentdb + https://www.isdocumentdbreallymongodb.com/ might also be interesting.

We can maybe take a look at what exactly is failing in the case of Amazon DocumentDB, but it is definitely not MongoDB and as such will not necessarily get high priority from us (unless many people now pop up here and tell us they are also using Amazon DocumentDB, of course).

If I was you, I would ask the Infrastructure Team for an actual MongoDB instance for now 😆

[janpio]

A good first step would be for someone to help us to understand what query would work on DocumentDB that returns the same data as what @dgonsan mentioned above. With that, we could in theory start chipping away at these in some form.

Is there a local DocumentDB emulator? Being able to develop and test against a local database is almost unavoidable if we actually want to ensure that everything in Prisma works (by running our testsuite, which contains hundreds of thousands of queries - which makes it unviable to test via network).