Specify the generator to use for sharing schema files in different environments

Problem

What I want to do

prisma’s schema structure is simple, clear, and brilliant! I am planning to use prisma schema in several programming languages.

For example, let’s assume the following case: Nodejs will handle the web server functions, and python will handle the once-a-day batch aggregation from the database. I want to use prisma-client-js to connect from node and prisma-client-py to connect from python. I believe that the benefit gained is quite large if one schema can be shared by multiple environments and programming languages. (For example, it could be a shared language for exchanging data such as protocol-buffer.)

Current issues

There are three items living together in the schema.prisma file: datasource, generator, and model. Of these, only model is an important part of the data handling schema. The datasource part is useful for generating connection methods, but the generator part is more dependent on each environment. For example, if you want to share a schema between the above two languages, a simple description would look like this.

generator client-js {
  provider = "prisma-client-js"
}

generator client-py {
  provider = "prisma-client-py"
}

However, this will not work as expected, because one of the two generator will output an error if both are not installed.

Suggested solution

I need a way to select and execute only what I need in the arguments. For example :

prisma generate --schema ./schema/schema.prisma --generator client-js

It would also be great if you could specify multiple generators. Alternatively, it may be better to have the generator part specified by each user as an add-on.

Alternatives.

There is currently a way to force a workaround using environment variables.

generator client {
  provider = env(PRISMA_CLIENT)
}

I have created a sample that uses this method. https://github.com/arika0093/prisma-multi-language

However, the drawback is that there is a lot of work to specify, and it is a bit of a hack.

Additional context

Creating a schema first, and then automatically creating the fetch code and database from there, will cause a paradigm shift in system development. I think it would be pretty cool to have a system where only the schema.prisma is managed in git and each project can refer to it from there. What are your thoughts on this? I’d appreciate your input.

[RobertCraigie]

@arika0093 In the meantime, another alternative solution would be to automatically create the Prisma Schema file, this is also very hacky but would allow you to configure the generators. For example:

python.prisma

generator py {
  provider             = "prisma-client-py"
  recursive_type_depth = -1
}

node.prisma

generator js {
  provider = "prisma-client-js"
}

models.prisma

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

model Post {
  id        Int     @id @default(autoincrement())
  title     String
  content   String?
  published Boolean @default(false)
  author    User?   @relation(fields:  [authorId], references: [id])
  authorId  Int?
}

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
  posts Post[]
}

Then to automatically create the Prisma Schema file you can use the following script

update_schema.sh

#!/bin/bash

LANGUAGE="$1"
if [ -z "$LANGUAGE" ]; then
  echo "You must pass the target language as the first argument to the script"
  exit 1
fi

cat "$LANGUAGE.prisma" "models.prisma" > schema.prisma

And use it like so:

./update_schema.sh python
prisma generate

[RobertCraigie]

Hey @partmor! Unfortunately the workaround I suggested is still the best solution to my knowledge.

Also a note about your point of not installing Node for a Python microservice, with the current architecture of the CLI the Python client in essence already installs Node through the packaged CLI which includes Node in the binary. The size of the packaged CLI is smaller than a standard install of Node but it is still not insignificant.

It should also be noted that I’m actively working on refactoring the way the Python CLI works so that it doesn’t use the packaged CLI and instead downloads Node for you if you don’t already have it installed, see https://github.com/RobertCraigie/prisma-client-py/pull/454. re size concerns, you will be able to install the python package with Node included which will result in equivalent storage requirements to the current packaged CLI.