Introduction

Prisma 2 defines core primitive types (in this document used interchangeably with Prisma scalar), all connectors implement this types natively or as best effort implementation. There are a couple of questions I have on how this would play with custom types.

Use Cases

A custom type that cannot be backed by a Prisma scalar

To support custom types, we can create a type alias in the Prisma schema file and back it by a Prisma core type. Let us use Postgres's BIGINT as an example.

We could define this type as following but assume that the Int core type of connector's programming language (Say we are writing Postgres connector in JS) is not big enough for the underlying data source's (in this case Postgres's) BigInt

// Not possible in a JS connector as JS integer cannot hold Postgres's BIGINT (Yet, soon™: https://v8.dev/blog/bigint)
type LargeNumber = Int @pg.BIGINT

So, we defined a type and use it like this backing a BIGINT with a String:

type LargeNumber = String @pg.BIGINT

model Planet {
  id Int @id
  population LargeNumber
}

These lines have enough information to generate a Photon client that has the following API (say, for create):

photon.planet.create({
  data: {
	  population: "123123212"
  }
})

This usage might require coercion in Photon or the query engine or the data source itself. What/where it exactly happens needs further spec.

Related notes:

• Same question can be asked for types that are not representable with an existing Prisma core type like BLOB. Will we add more Prisma core primitive types?
• How does type Json = String @pg.json behave if the user input is not valid JSON → Does photon or some other part of stack reject it? What part of stack identifies an input variable as JSON and tries to coerce/parse it?

Related spec issue for capabilities: #8