Why?

You should be using the same database for development as in production. Sometimes this is not feasible, but for the databases we currently support, it's fortunately very easy to setup. We just need to guide our users how.

For example

Additional Notes

• We may need to provide instructions on how to install brew or some installable .dmg if available
• I think we should also optionally provide a way to run these database as a service so they bootup on start. In homebrew that's easy brew services start postgres.

On the following doc page (https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-schema/relations) there are multiple tags with the id of #example which breaks hyperlinks and isn't proper HTML. I haven't checked the other pages, but I assume this is probably happening elsewhere as well!

In order for scripts to disconnect the Photon client, some boilerplate is needed. This should be documented.

import { Photon } from '@generated/photon'

const photon = new Photon()

async function main() {
  const result = await photon.flats.findMany()
  console.log(result)
}

main()
  .catch(e => console.log(e))
  .finally(() => photon.disconnect())

https://prisma2.netlify.com/favicon.ico doesn't work.

This is applies to all static images which don't seem to be copied to the generated public folder

https://prisma2.netlify.com/guides/deployment/deploying-to-netlify

We need to find a way to update the old P1 docs to include a link in the version switcher for the Prisma 2.0 docs that links to https://www.prisma.io/docs/

Reproduce: Select the last item of the TOC on this page:

https://prisma2.netlify.com/reference/tools-and-interfaces/prisma-schema/relations

prisma introspect recently added Introspection Warning messages to communicate to the user about guardrails that were applied during Introspection. This currently looks like this:

We want to document these individually and offer workarounds.
Additionally the error messages itself should be improved and link to the matching documentation.

PRs:

• Engine PR to change error message (with link): prisma/prisma-engines#638
• Docs PR to add warning messages with description and workaround: #72
• Pris.ly PR to add short links for docs sections: prisma/pris.ly#3

Documentation only version of prisma/prisma#1749 (comment)

possibly a .. missing

Is this the expected rendering for Markdown quotes?

This is the corresponding Markdown:

> **Note**: The content on this page is focused on **relational databases**.

The links in the table of contents don't seem to work.

For example, https://prisma2.netlify.com/04-guides/02-deployment/01-deploying-to-zeit-now#prerequisites doesn't navigate to the correct section.

Right now an expanded section collapses when I select a page:

Before

After

The Prisma schema section collapsed after I clicked on a page:

Expected

It should stay expanded:

What

In a similar fashion to how we have a Filtering section, we should add a section on pagination.

Why

• The API has changed for before and after which now accept *WhereUniqueInput, e.g. UserWhereUniqueInput instead of a string.
• It can be used to enable pagination based on arbitrary uniques.

Example

Before:

const paginatedPosts3 = await prisma.post.findMany({
  first: 5,
  after: 43834,
})

After:

const paginatedPosts3 = await prisma.post.findMany({
  first: 5,
  after: { id: 43834},
})

Example:

```js copy
async function main() {
  const allUsers = await prisma.user.findMany()
  console.log(allUsers)
}
```

This issues persists a docs requests from Slack:

In Prisma 1 there is not a lot of information about deployment. Specifically for creating a CI/CD workflow. For instance creating a staging and production environments and rolling out incremental updates. I would love to see more information around production best practices with Prisma 2. As well as more options/info about deployments.

It always surprises me how many mobile users you get on a launch. Right now we don't do a good job handling them.

For now, we can just use a scaled down version of the website. You probably just need to add:

<meta name="viewport" content="width=device-width, initial-scale=1" />

E.g. when being on the Prisma schema file page the sidenav is not expanded properly when:

• You reload the page
• Land on this page via an external link
• Open this page via the top nav

Example: (this page works)
https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-migrate

But the canonical of this page is
https://www.prisma.io/docs/03-reference/01-tools-and-interfaces/03-prisma-migrate

Which is a 404 - That means that Google will not index all the pages that have a broken canonical

NestJS provides an example for the old prisma1 using prisma-binding (https://github.com/nestjs/nest/tree/master/sample/22-graphql-prisma).
Can you provide a new sample integration for prisma2? The part I find most lacking is the @ResolveProperty() implementation as this is something usally done with a dataloader but I can't get what is the best practice when using prisma2.

This text should be rendered with a new line:

> **Note**: In SQL, relations between models are represented via _foreign keys_ in the underlying database. A foreign key is only stored on _one_ side of a relation. As opposed to how relations are modeled in SQL, **Prisma always requires explicit relation fields on _both_ sides of the relation to be set on your Prisma models**.
> 
> This means that one side of the relation represents the _foreign key_ in the underlying database, the other relation field is provided on a Prisma-level (in the case of implicit many-to-many relations, both relation fields are provided on a Prisma-level).

Like so:

Note: In SQL, relations between models are represented via foreign keys in the underlying database. A foreign key is only stored on one side of a relation. As opposed to how relations are modeled in SQL, Prisma always requires explicit relation fields on both sides of the relation to be set on your Prisma models.

This means that one side of the relation represents the foreign key in the underlying database, the other relation field is provided on a Prisma-level (in the case of implicit many-to-many relations, both relation fields are provided on a Prisma-level).

In the doccs it currently gets rendered as:

I read this section on managing connections in your docs and I found it a bit confusing.

To start, the important note is not very clear… I don’t understand what the scenario is in which the Prisma Client doesn‘t do the right thing. A better explanation and a code snippet showing the problem would be really helpful.

Additionally, the important note simultaneously says that the Prisma Client should just do the right thing but also says that sometimes it won’t. I think it should be one or the other. If the client can be made such that it always does the right thing, then great! If not, don’t even mention it, just clearly explain what someone has to do to protect themselves.

Which leads into the last problem… which is that I don’t know where to call prisma.disconnect(). Right now I’m just peppering disconnects after every query—that’s clearly not right.

I’m using Express, so… would the generally correct thing be to use a middleware to disconnect at the end of the request/response cycle?

import { PrismaClient } from "@prisma/client"
const prisma = new PrismaClient()

express.use(function(req, res, next) {
  res.on("finish", () => prisma.disconnect())

  next()
})

I took a look at the Prisma Client repo but because of the way it’s built I can’t tell if when I instantiate a new PrismaClient is it returning the same instance (a singleton) or am I getting a new instance? Rather, it’s unclear if calling prisma.disconnect() in this way would actually disconnect all connections, or just the connections that were specifically started with this instance of the client.

Problem

Users are using prisma.raw() like

const data = await prisma.raw(
  `SELECT * FROM "ProviderItemAttribute" WHERE "provider_item" = ${root.id} AND "user" = ${auth.user.id} limit 1;`,
);

This example is using prisma.raw() the pure text version so there is no security around parameters.

Only raw`` is secure because it's using https://github.com/blakeembrey/sql-template-tag

Solution

In this case it would be recommended to do

const data = await prisma.raw`
	SELECT * FROM "ProviderItemAttribute" WHERE "provider_item" = ${root.id} AND "user" = ${auth.user.id} limit 1;
`;

This should be highlighted in the docs (and examples?)
We also can think about how to warn users that are using prisma.raw() or even disable it under a flag?

Note prisma.raw`` parameters do not work as of today with PostgreSQL see prisma/prisma-client-js#595

PRISMA_MIGRATION_ENGINE_BINARY 		// migration-engine
PRISMA_QUERY_ENGINE_BINARY 			// query-engine
PRISMA_INTROSPECTION_ENGINE_BINARY	// introspection-engine

In previous docs these were only documented in context of the generator:
https://github.com/prisma/prisma2/blob/7b254e8e90ec45370de41b5551cc401a710cbd2f/docs/core/generators/prisma-client-js.md#generator-options

Issues like prisma/prisma#1333 show that this is also considered in other contexts like when the automated download of the binaries is not possible (for whatever reason).

In the meantime 1 new var appeared for the prisma-fmt (format):

PRISMA_FMT_BINARY					// prisma-fmt

Once this spec is ready: prisma/specs#113

It's a pretty common "convention" (?) to have this subdomain work, I found myself typing it in multiple times.

I'm also not sure if this is the right place to create the issue, so please move / close if it isn't~

Problem

I can not find any documentation for working with ternary relations.
As such, I'm not sure if and how they are supported. The documentation only seems to show very simple queries.

This is a basic task in SQL where many ORM's fall flat which leads developers like myself to keep reaching for SQL.

From your own marketing:
"For database access, developers can use traditional ORMs (e.g. Sequelize for Node.js or GORM for Go). While often beneficial to get a project off the ground, these aren't a good longterm fit as project complexity quickly outgrows the capabilities of traditional ORMs."

But there is no information about how Prisma can actually succeed where other ORM's fail.

A common example is group permissions for users as demonstrated by the following table structures:

There are two common views that people would want for such data. I have given each view for the first and second schema respectively:

User view:

users =  [
{
    user_id: 2;
    groups: [
        {
            group_id: 4;
            permissions: {
                permission_id: 2;
            };
        },
    ];
}
]

users = [
{
    user_id: 2;
    groups: [
        {
            group_id: 4;
            permissions: [
                {
                    permission_id: 2;
                },
            ];
        },
    ];
}
]

Group view:

groups = [
{
    group_id: 2;
    users: [
        {
            user_id: 4;
            permissions: {
                permission_id: 2;
            };
        },
    ];
}
]

groups = [
{
    group_id: 2;
    users: [
        {
            user_id: 4;
            permissions: [
                {
                    permission_id: 2;
                },
            ];
        },
    ];
}
]

As well as viewing this data, it is also important that we can filter and sort by it as we could in SQL. For instance, one may which to answer the following query: 'Find all the groups where user A has permissions B'.

Finally, these relationships should be able to be derived using introspection (assuming that they have foreign key relationships).

Solution

Prisma should clearly state in the documentation (with examples) how introspection and queries work with ternary and other complex relationships. Showing how Prisma can elegantly overcome this issue is important for proving that it worthy of use in production applications and different from "traditional ORMs".

Hi. In the microservices setup I have, so far, I have been having the migrations generated and kept along with my service code. But, to have better separation of concerns and have a proper CI/CD pipeline, I want to separate out the service as well as the database migrations to 2 repos.

The only problem I have is that, both the service and the database uses schema.prisma file. Service for running prisma2 generate and DB for running prisma2 migrate and thus, if I change the schema.prisma file, I have to change in 2 places leading to duplication and possible mistakes.

Is there any way to avoid this or any better strategy to separate it? With service in 1 repo and migrations in another repo with their own CI/CD pipelines.

Library authors sometimes need access to lower-level functionality of Prisma Client that's not available via the "official" Prisma Client API.

Often this involves access to the private dmmf property of Prisma Client. When documenting this, we have to make sure that it's clear that this is an "unofficial API" that might break in any release and should therefore be used with great care.

See prisma/prisma#1286 (comment)

Documentation only ever shows ability to connect to a single record during create(), e.g.

// Create a new user
const newUser = await photon.users.create({
  data: {
    name: 'Alice',
    email: '[email protected]',
    posts: {
      connect: {
        title: 'hello world'
      }
    }
  },
})

Is it possible to connect a new author to several posts all at once?

Example on the Quickstart page: https://www.prisma.io/docs/getting-started/quickstart

Prisma internally uses binaries for the query, migration and (soon) introspection engines. Those are used by photon and lift just fine, but it would still be good to have their "external" API documented so this information is made more explicit.

This can either happen in a spec or simple READMEs in the prisma-engine repository next to the code (I prefer the README, as this really is just documentation of an implementation detail. In specs I would expect a more generalized "list of functionality" or similar).

When I try to have a heading on page that uses inline coee with backticks like so:

#### The `native` binary target

The page shows an error:

Note the ) at the end of the link

[email protected], binary version: 1b0c271f14ca00606f56c93717e228fe48c5603c
MacOS 10.13.6

Here's my schema.prisma file:

generator photon {
  provider = "photonjs"
}

datasource db {
  provider = "sqlite"
  url      = "file:dev.db"
}

model User {
  id    String  @default(cuid()) @id
  email String  @unique
  name  String?
  post  Post
}

model Post {
  id        String   @default(cuid()) @id
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  published Boolean
  title     String
  content   String?
  author    User?
}

Which generates the following type in index.d.ts:

export declare type User = {
    id: string;
    email: string;
    name: string | null;
};

Despite there being a post field in the database, it doesn't exist in the generated type.

Sometimes it's helpful to wipe all data records in the DB but keep the tables. This is currently not possible via the Prisma Client API so we should document a workaround.

One potential approach which currently doesn't work because it relies on a private property of PrismaClient is this:

import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()

function lowerCase(name: string): string {
  return name.substring(0, 1).toLowerCase() + name.substring(1)
}

const promises = prisma.dmmf.datamodel.models.map(model => {
  return new Promise(async resolve => {
    const modelName = lowerCase(model.name)
    const modelMethods = prisma[modelName]

    if (modelMethods) {
      try {
        resolve(await modelMethods.findMany({}))
      } catch (e) {
        resolve(e)
      }
    }
  }

async function main() {                    
  await Promise.all(promises)
}

main()

Alternatively, the following approach (by @nnennajohn) which is based on knex.js can be used:

import camelCase from 'lodash/camelCase';
import { prisma } from '@cpath/universal/shared/db';
import knexClient from './knex';
// Contents of the knexClient import above
// import Knex from 'knex';
// const knexClient: Knex = Knex({
//   client: 'pg',
//   connection: {
//     user: process.env.POSTGRES_USER,
//     password: process.env.POSTGRES_PASSWORD,
//     host: process.env.POSTGRES_HOST,
//     port: Number(process.env.POSTGRES_PORT),
//     database: process.env.POSTGRES_DB,
//   },
// });
// Contents of the prisma import above
// export const prisma = new PrismaClient();
function deleteRecords(tablesList) {
  const validTables = tablesList.filter((tableName) => tableName[0] !== '_');
  console.log('These are the valid tables', validTables);
  const recordsDeletions = validTables.map((table) => {
    return prisma[camelCase(table)].deleteMany({});
  });
  return Promise.all(recordsDeletions);
}
function listTables() {
  const query =
    'SELECT table_name FROM information_schema.tables WHERE table_schema = current_schema() AND table_catalog = ?';
  const bindings = [knexClient.client.database()];
  return knexClient.raw(query, bindings).then((results) => {
    return results.rows.map((row) => row.table_name);
  });
}
async function main() {
  const tablesList = await listTables();
  console.log('This is the list of knex tables', tablesList);
  if (tablesList && tablesList.length) {
    deleteRecords(tablesList)
      .then((res) => {
        console.log('Successfully deleted table records', res);
      })
      .catch((err) => {
        console.log('Error deleting table records', err);
      });
  }
}
main()
  .catch((e) => console.error(e))
  .finally();

We should also document a workaround that allows to do this without an external dependency like knex.js.

https://github.com/prisma/prisma2/blob/master/docs/prisma-client-js/api.md#crud

To be able to run this the main invocation is missing, it is in TypeScript which might not be obvious (it was not to me...), and there is no console.log or similar to output the returned data.

with link text comments

Without backticks:

With backticks:

A.k.a. SDK

Hello, I'm working on a monorepo with yarn workspaces and I would like to use Docker for alternate with dev and prod mode and it feels a little bit complicated.

This is the architecture of the project. And I was telling me that it would be great to have an example to make this working because a lot of people could be interested.

Thanks

If you have a generator in your schema.prisma like this:

generator testutils {
  provider = "./node_modules/prisma-test-utils/dist/generator.js"
  output = "./node_modules/@generated/prisma-test-utils"
}

The output is actually generated in ./prisma/node_modules/@generated/prisma-test-utils:

✔ Generated Prisma Test Utils to .\prisma\node_modules\@generated\prisma-test-utils in 3.95s

That was unexpected to me.

Changing output to use ../node_modules... fixes the problem.

(Could potentially also be the fault of the generator I am trying to use.)