Potentially consolidate @id and @db.ObjectId

Problem

Right now, it’s cumbersome to add @id and @db.ObjectId.

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

To quote one of our early users:

The only thing that I didn’t understand was why is @db.ObjectId required in the schema when I already wrote @id

The reason for this is to keep the concepts orthogonal:

• @id means primary key (not null + unique)
• @db.ObjectId tells you that it’s a specific native type (BSON ObjectID type)

This is quite nuanced and we should think about ways to consolidate this for at least the common cases.

[dpetrick]

Our stance on the current iteration of the schema language is pretty firm in reducing magic opinionations. The DSL should be consistent for a broad variety of connectors with no need to learn intricacies and caveats when using different connectors. There is 100% a discussion to be had about manageability of the schema when it gets unwieldy like id String @id @default(dbgenerated()) @map("_id") @db.ObjectId.

why isn’t it required to specify INT as a type for the SQL databases? like in PG you can set ID type to string. Prisma just assumes that a default type is an integer. why then it can’t assume that the default type for Mongo id is ObjectID? just use it as a default, but allow people to override it if they wanna use any other type

This would be inconsistent with the DSL type representation and I hope the explanation above sheds some light on this. A string is a string and nothing specialized like an ObjectID, this default is consistent in the Prisma world.

If you are really unhappy about the current ergonomics of the Mongo ID, then I propose you just alias it and be done with it (yes, this exists and works already):

type MongoID = String @id @default(dbgenerated()) @map("_id") @db.ObjectId

model User {
  id   MongoID
  name String
}

The above is an undocumented schema feature and we will make breaking changes to this in the future.

[matthewmueller]

We’re going to close this since we do want to keep the concepts orthogonal.

In the future, I could see us supporting aliases, similar to: https://github.com/prisma/prisma/issues/6839#issuecomment-875423822 but not overriding existing attributes.