Today, we are issuing the 2.1.3 patch release.

Fixes and improvements

Studio

• Roll back new table view due to regressions

Today, we are issuing the 2.1.2 patch release.

Fixes and improvements

Studio

• New table grid component

Prisma Client

• Transaction API is not writing the transaction #750
• JSON Filter does not work #745

Today, we are issuing the 2.1.1 patch release.

Fixes and improvements

prisma migrate

• Mask datasource URLs in migration files to avoid leaking credentials
• Migrate migration writes credentials out in the readme file

Today, we are issuing the 2.1.0 stable release.

Major improvements

Next to a lot of bug fixes, this version includes a number of new features.

Basic filtering on Json data in Prisma Client

When querying data, you can now perform basic filtering with Json fields using equal and not:

const jsonData = [
  {
    array1key: 'array1value',
  },
]

// `equal` filter. Return all posts with this particular `jsonData`
const result = await prisma.post.findMany({
  where: {
    jsonData
  },
})


// `not` filter. Return all posts, which don't have this `jsonData`
const result = await prisma.post.findMany({
  where: {
    jsonData: { not: jsonData }
  },
})

📚 Documentation: Working with Json fields

A sample Prisma schema for the example above could look like this:

model Post {
  id        Int     @id @default(autoincrement())
  title     String
  content   String?
  jsonData  Json
}

Hide the Prisma CLI update message

You can now hide the Prisma CLI update notifier message by setting the environment variable PRISMA_HIDE_UPDATE_MESSAGE (e.g. to "1", "true" or "asd").

export PRISMA_HIDE_UPDATE_MESSAGE="1"

Prepared statement caching for PostgreSQL

Under the hood, we enabled prepared statement caching for PostgreSQL. This way Prisma Client's query engine does not repeatedly prepare the same statement but can reuse an existing one which reduces database CPU usage and query latency.

Many bug fixes for Prisma VSCode Extension

The Prisma VSCode extension received an extraordinary number of tiny fixes this release, which will make using it much more pleasant. Give it a try!

Experimental features

With the GA release of Prisma 2.0, you can expect much more stable releases in the future. At the same time, we of course want to be able to release new features that are fresh from our developers for you to try out. This is the best way we can get them stable enough to be generally available.

We are doing this with experimental features.

🚨 The following features are not part of our official and stable API and may be changed or removed completely in a future release.

Enabling experimental features in Prisma Client

With this release, we introduce feature flags for Prisma Client. Similar to the --experimental flag in the CLI (for prisma studio and prisma migrate), this enables us to hide functionality from the default API that all users get when installing Prisma and Prisma Client. Instead, users can explicitly opt-in to certain features by enabling them via the new experimentalFeatures field on the Prisma Client generator definition in their Prisma schema.

The experimentalFeatures field can be set like this:

generator client {
  provider = "prisma-client-js"
  experimentalFeatures = ["connectOrCreate", "transactionApi"]
}

Read more below to learn about the connectOrCreate and transactionApi experimental features.

connectOrCreate

When updating or creating a record, we now provide a new operation as a nested mutation: connectOrCreate.
You can connect (if exists) or create (if it doesn't exist) to a related row.

📚 Documentation: Relation queries: connectOrCreate

Example

In this example, we create a new post and connect it to an author with the email address [email protected]. If that author doesn't exist yet, create it with the name "Alice".

await prisma.post.create({
  data: {
    title: 'Prisma 2.1.0',
    author: {
      connectOrCreate: {
        where: {
          email: "[email protected]"
        },
        create: {
          name: "Alice",
          email: "[email protected]"
        }
      }
    }
  }
})

Feature flag

To enable connectOrCreate, you can use the feature flag connectOrCreate in your Prisma schema file:

generator client {
  provider = "prisma-client-js"
  experimentalFeatures = ["connectOrCreate"]
}

Please share your feedback on how this feature works for you. We are interested in both positive and negative feedback, so we know if this feature is already ready for production! (If encounter any problems, please open a new issue here).

transactionApi

While Prisma already ships transactions within nested writes, there are many use cases, where you might want to perform multiple unrelated write operations in a transaction and rollback, if one of them fails. By wrapping your write operations in the new transaction() function, you can achieve exactly this!

(Note, that these transactions are not long-running and are executed directly after each other. This is an explicit design decision of Prisma. In case this does not cover your use case yet, please chime in on GitHub).

Example

//run inside `async` function
await prisma.transaction([
  prisma.user.create({
    data: {
      email: "[email protected]",
    },
  }),
  prisma.user.create({
    data: {
      email: "[email protected]",
    },
  }),
])

Alternatively, you can store the unresolved promises in variables and pass these to the new transaction function:

const userOperation1 = prisma.user.create({
  data: {
    email: "[email protected]",
  },
})

const userOperation2 = prisma.user.create({
  data: {
    email: "[email protected]",
  },
})


//run inside `async` function
await prisma.transaction([userOperation1, userOperation2])

Feature flag

To enable the experimental transaction api, you can use the feature flag transactionApi in your Prisma schema file:

generator client {
  provider = "prisma-client-js"
  experimentalFeatures = ["transactionApi"]
}

Please leave feedback on how this feature works for you https://github.com/prisma/prisma-client-js/issues/667. We are interested in both positive and negative feedback, so we know if this feature is already ready for production. (If there are problems you can also open a new issue here).

Enabling experimental features in the Prisma CLI

In the Prisma CLI, we are using dedicated experimental flags that can be added to any command.

Re-Introspection

One common problem when using Prisma is that manual changes to your Prisma schema are overwritten the next time you run prisma introspect. This version adds an experimental mode for this functionality where we try to keep some of these changes:

• Custom names for relation fields
• @@map on models and enums
• @map on fields and enum values

You enable this by supplying the --experimental-reintrospection flag to prisma introspect:

npx prisma introspect --experimental-reintrospection

Please leave feedback on how this feature works for you https://github.com/prisma/prisma/issues/2829. We are interested in both positive and negative feedback, so we know if this feature is already ready for production. (If there are problems you can also open a new issue at here).

Fixes and improvements

prisma

• Panic on a table that only has an ID, "called Option::unwrap() on a None value"
• .raw errors on date params w/ Postgres
• Improve error handling for incorrect raw parameters
• Parameter for prisma init to supply connection string to be used in datasource
• Configuration to disable update check and message
• queryRaw Error when calling SP or Function
• ENV var is required to execute generate/validate
• Tighten Version Check for P1 and P1.1 further
• Getting dbgenerated() for defaults on enums in Postgres
• Environment variables loaded from uses wrong directory separator (slashes) on Windows
• ENOENT when running prisma with pkg
• Statement caching for PostgreSQL
• CI Pipeline: Release stable release from chosen dev instead from current master state
• mixing uuid's with strings
• @prisma/debug logs in tests
• Clean up datasources in Prisma Client constructor parameters

prisma-client-js

• create OR connect on nested writes (upsert)
• Query batching & transactions support
• Deeply nested creation never completes
• Prisma DMMF JsonFilter input has no fields
• Client, Engine version incorrect when overriding binary with Prisma client constructor
• Adapt a more conflict resistant naming for Prisma client's types
• JSON type throws error on certain types of valid JSON on create and update
• Remove __internal from types

vscode

• [Publishing] Send message to Slack channel on publish (success or failure)
• Different README for unstable extension version
• Notify Slack channel on extension publish
• Trigger CI tests after bumping the version and before publishing
• Remove type_alias from auto-completion
• Add auto-completion for env()
• Cursor should stay inside [] for auto-completion
• Autocompletion suggests block types after enum definition
• Auto-completion does not suggest block types when typing
• Clean build before publish
• Run integration tests on multiple platforms
• Document "format on save" in READMEs
• Add Prisma Version and Insider Version to Slack Notification Message

studio

• Studio startup doesn't work (ENOENT)

prisma-engines

• Clarify CURRENT_TIMESTAMP support across MySQL versions
• Avoid relying on JSON database migrations backwards compatibility
• Introduce debugging mode to trigger panics in query engine
• Nested cursor-based pagination doesn't work as intended
• Move Windows build to GitHub Actions

Today we release the first patch release 2.0.1.
This is the first time that we run our new patch process! And it looks like everything went well 🤗.

Improvements

• The database detection in prisma introspect got improved so there are fewer false positives that tell users their database is Prisma 1.

🎉 Today, we are launching Prisma 2.0 for General Availability! Read the announcement to learn more.

💡 What is Prisma 2.0?

Today's General Availability release features Prisma Client, a type-safe and auto-generated query builder for your database. Thanks to introspection, Prisma Client can be used for existing databases as well.

Note: Prisma Migrate and Prisma Studio are not part of today's release. They're still experimental.

🚀 Getting started

The easiest way to get started is by following the Quickstart (5 min). It is based on a SQLite demo database and doesn't require any setup!

You can also connect Prisma to your own PostgreSQL or MySQL database, either in an existing project or when starting from scratch.

✉️ Let us know what you think

As always, we very much appreciate your feedback! Please don't hesitate to reach out here on GitHub or on Slack if you have any questions, thoughts, or any other kind of feedback about Prisma! 🙌

⬆️ Upgrading from Prisma 1

If you're currently using Prisma 1 and want to upgrade to the new version, you can start by learning about the upgrade process in the docs: How to upgrade 📚

If you have any questions or feedback about the upgrade process, please create a GitHub issue in our new feedback repo. You can also share your personal feedback path with us and we'll try to figure out the best way to upgrade with you!

We're also planning upgrade webinars, where we're demoing the upgrade process for different scenarios (e.g. using prisma-binding, Prisma Client, Nexus, ...). The webinars are currently planned for July, we'll announce the dates soon!

🌎 Join us online for Prisma Day on June 25th and 26th

We're hosting another edition of Prisma Day this year and are going fully remote. Join us online for hands-on workshops on June 25th and great talks on June 26th. Some of the speakers include GitHub co-founder Tom Preston-Werner, Netlify CEO Mathias Biilmann Christensen and lots of Prisma folks to tell you the latest about Prisma 2.0.

Today, we are issuing the ninth Beta release: 2.0.0-beta.9 (short: beta.9).

Enforcing arrays in OR

We used to allow this syntax:

  const orIncorrect = await prisma.post.findMany({
    orderBy: {
      id: 'asc'
    },
    where: {
      OR: {
        title: {
          equals: "Prisma makes databases easy"
        },
        authorId: {
          equals: 2
        }
      }
    }
  });

However, the thing that we want is this:

const orCorrect = await prisma.post.findMany({
   orderBy: {
     id: 'asc'
   },
   where: {
     OR: [{
       title: {
         equals: "Prisma makes databases easy"
       },
     }, {
       authorId: {
         equals: 2
       }
     }]
   }
 })

So only the array syntax makes sense, therefore we also only allow that from now on.

Fixes and improvements

prisma

• Expose a logger interface
• Emit an error event when the database connection is interrupted
• Limit implicit m-n relations to primary keys only
• Rename pinnedPlatform to pinnedBinaryTarget
• @prisma/engine-core forces users to enable esModuleInterop

prisma-client-js

• findMany / OR accepts non-array value - should only accept arrays
• Queries and mutations stuck (runs forever?) if log option is ['query', 'warn']

vscode

• Ctrl+Space suggests type after type
• suggest ? after type
• Add JSON to auto-completion types

prisma-engines

• Use exact id column type for the version check during introspection
• add uniqueIndexes to Model in DMMF
• bring back default for Field in DMMF

Credits

Huge thanks to @Sytten for helping!

Today, we are issuing the eighth Beta release: 2.0.0-beta.8 (short: beta.8).

Breaking change: Splitting .raw into .queryRaw and .executeRaw

When dealing with raw SQL queries, there are two things we care about - the "return payload", which is being calculated by the SELECT statement we use and the number of affected rows - if we for example do an UPDATE query.

Until now, Prisma Client decided under the hood with a heuristic, when to return the number of affected rows and when to return the result data.
This heuristic broke if you wanted the opposite of what the heuristic returned.
That means that the decision has to be made by the developer using Prisma Client instead.
Therefore, we remove the raw command and replace it with executeRaw and queryRaw.

So what does return what?

• executeRaw returns the number of affected rows
• queryRaw returns the result data

The heuristic used to return the data for SELECT statements. So if you upgrade to Beta 8, you need to use queryRaw for your SELECT statements and executeRaw for all SQL queries, which mutate data.

The rule of thumb is: Do not use executeRaw for queries that return rows.
In Postgres, it will work to use executeRaw('SELECT 1), however, SQLite will not allow that.

Fixes and improvements

prisma

• Make sure Netlify deployments are not listed with their .netlify.com domain in Google and Co
• .raw doesn't return data if query doesn't start with SELECT statement
• Prisma 2.0.0-beta.7 npx prisma generate issue if working directory contains spaces
• JSON type is broken for array. Array comes back as string.
• Error: spawn node --max-old-space-size=8096 .\node_modules@prisma\client\generator-build\index.js ENOENT
• Add a test case for project paths with spaces

prisma-client-js

• Prisma Client removed on adding a new package: Error: @prisma/client did not initialize yet
• JSON types should return a JSON object and not a JavaScript object
• Datasource override from client constructor doesn't match the datasource block from the schema.prisma file

Credits

Huge thanks to @Sytten, @merelinguist for helping!

Today, we are issuing the seventh Beta release: 2.0.0-beta.7 (short: beta.7).

New Pagination

Prisma Client's pagination has been simplified a lot!

• Removed first, last, before, after arguments.
• Added cursor and take arguments.
• skip argument unchanged.

The take argument replaces first and last.

Examples

first

prisma.user.findMany({
  first: 10
})

// becomes
prisma.user.findMany({
  take: 10
})

last

prisma.user.findMany({
  last: 10
})

// becomes
prisma.user.findMany({
  take: -10
})

before

prisma.user.findMany({
  before: "someid"
  first: 10
})

// becomes
prisma.user.findMany({
  cursor: "someid"
  take: -10
  skip: 1
})

after

prisma.user.findMany({
  after: "someid"
  first: 10
})

// becomes
prisma.user.findMany({
  cursor: "someid"
  take: 10
  skip: 1
})

The record specified with cursor is now included in the results, making skip: 1 necessary if you want to preserve the previous before / after semantics.

This diagram illustrates how the pagination works:

             cursor: 5                              
             skip: 0 or undefined                   
                       │                            
                       │                            
                       │                            
                       ▼                            
 ┌───┐┌───┐┌───┐┏━━━┓┏━━━┓┌───┐┌───┐┌───┐┌───┐┌───┐ 
 │ 1 ││ 2 ││ 3 │┃ 4 ┃┃ 5 ┃│ 6 ││ 7 ││ 8 ││ 9 ││10 │ 
 └───┘└───┘└───┘┗━━━┛┗━━━┛└───┘└───┘└───┘└───┘└───┘ 
                ◀────────                           
                 take: -2                           
                                                    
                                                    
                                                    
                    cursor: 5                       
                     skip: 1                        
                        │                           
                        │                           
                        │                           
                        ▼                           
  ┌───┐┌───┐┏━━━┓┏━━━┓┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐
  │ 1 ││ 2 │┃ 3 ┃┃ 4 ┃│ 5 ││ 6 ││ 7 ││ 8 ││ 9 ││10 │
  └───┘└───┘┗━━━┛┗━━━┛└───┘└───┘└───┘└───┘└───┘└───┘
                 ◀────────                          
                  take: -2                          
                                                    
                                                    
                                                    
                    cursor: 5                       
                     skip: 2                        
                        │                           
                        │                           
                        │                           
                        ▼                           
  ┌───┐┏━━━┓┏━━━┓┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐
  │ 1 │┃ 2 ┃┃ 3 ┃│ 4 ││ 5 ││ 6 ││ 7 ││ 8 ││ 9 ││10 │
  └───┘┗━━━┛┗━━━┛└───┘└───┘└───┘└───┘└───┘└───┘└───┘
                 ◀────────                          
                  take: -2                          
                                                    
                                                    
            cursor: 5                               
            skip: 0 or undefined                    
                      │                             
                      │                             
                      │                             
                      ▼                             
┌───┐┌───┐┌───┐┌───┐┏━━━┓┏━━━┓┏━━━┓┌───┐┌───┐┌───┐  
│ 1 ││ 2 ││ 3 ││ 4 │┃ 5 ┃┃ 6 ┃┃ 7 ┃│ 8 ││ 9 ││10 │  
└───┘└───┘└───┘└───┘┗━━━┛┗━━━┛┗━━━┛└───┘└───┘└───┘  
                      ──────────▶                   
                        take: 3                     
                                                    
                                                    
                  cursor: 5                         
                  skip: 1                           
                      │                             
                      │                             
                      │                             
                      ▼                             
┌───┐┌───┐┌───┐┌───┐┌───┐┏━━━┓┏━━━┓┏━━━┓┌───┐┌───┐  
│ 1 ││ 2 ││ 3 ││ 4 ││ 5 │┃ 6 ┃┃ 7 ┃┃ 8 ┃│ 9 ││10 │  
└───┘└───┘└───┘└───┘└───┘┗━━━┛┗━━━┛┗━━━┛└───┘└───┘  
                      ──────────▶                   
                        take: 3                     
                                                    
                                                    
                  cursor: 5                         
                  skip: 2                           
                      │                             
                      │                             
                      │                             
                      ▼                             
┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐┏━━━┓┏━━━┓┏━━━┓┌───┐  
│ 1 ││ 2 ││ 3 ││ 4 ││ 5 ││ 6 │┃ 7 ┃┃ 8 ┃┃ 9 ┃│10 │  
└───┘└───┘└───┘└───┘└───┘└───┘┗━━━┛┗━━━┛┗━━━┛└───┘  
                      ──────────▶                   
                        take: 3                     

Auto restart on panic

The Query Engine now automatically restarts with an exponential backoff with jitter, if it exits for some reason, for example in the case of a panic. That helps a lot to make Prisma Client more resilient in production!
https://github.com/prisma/prisma/issues/2100

Introspection now recognizes @default(cuid / uuid)

If you introspect a Prisma 1 schema, the introspection now correctly recognizes cuid or uuid usage
https://github.com/prisma/prisma/issues/2499

Fixes and improvements

prisma

• Prisma should check for generator binaries in $PATH
• A generator provider should accept arbitrary commands
• generate does not work in folders with spaces
• Restart engine on panic
• Unable to save arrays in a Json type field
• findMany with a select argument errors out with models with self-relations (sometimes)
• [Introspection] Identify Prisma 1 Id defaults
• Prisma Client mixes up DateTimes and IDs when they are selected in queries
• findMany fails to select an enum list & a relation scalar at the same time
• [Prisma Client] Duplicate identifier with models "X" and "XClient"
• Output notice about Prisma1->Prisma2 upgrade documentation and tool
• New raw functions not exported from @prisma/client
• Generated GitHub link too long

prisma-client-js

• Error when passing a null value to a nullable Json field type

vscode

• Message: Request textDocument/definition failed with message: Schema parsing
• Show linter snippet in formatting error
• Using svg breaks markeplace publish
• Not possible to use backslash in string field
• Run CI tests every time a release gets published
• Include CLI version in startup output
• Startup output does not include binary hash any more
• Using autocompletion for @default() puts curcor after ) instead of inside ()
• Ctrl+Space does not suggest current model for self relation
• @unique @unique
• Formatter adds new lines on every format call
• Move out anything unimportant to users from README to CONTRUBUTING.md
• Update README preview image
• Improving README
• vscode plugin formatting bug
• Auto-completion for relation directive shows wrong suggestions
• Format incorrectly deletes invalid lines
• Format deletes new lines in invalid block and removes any whitespaces in the beginning
• Format moves lines on every format call in an invalid schema

prisma-engines

• Implement simplified pagination

Credits

Huge thanks to @Sytten, @thankwsx, @zachasme for helping!

Today, we are issuing the sixth Beta release: 2.0.0-beta.6 (short: beta.6).

More powerful raw queries with Prisma Client

Thanks to @zachasme and @Sytten, the prisma.raw command became more powerful in https://github.com/prisma/prisma/pull/2311. There are two changes we introduce for raw:

Expose sql-template-tag helpers

Prisma Client's raw mode utilizes the sql-template-tag library. In order to construct raw SQL queries programmatically, Prisma Client now exposes a few helper functions:

import { sql, empty, join, raw, PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()

const rawQueryTemplateFromSqlTemplate = await prisma.raw(
  sql`
    SELECT ${join([raw('email'), raw('id'), raw('name')])}
    FROM ${raw('User')}
    ${sql`WHERE name = ${'Alice'}`}
    ${empty}
  `
)

Allowing programmatic positional parameters

Sometimes, a static template string is not enough. Then constructing a string dynamically is the right choice. For this situation, we added support for arbitrary positional parameters:

const result = await prisma.raw(
  'SELECT * FROM User WHERE id = $1 OR email = $2;',
  1,
  '[email protected]'
)

Other improvements

• You can now enable pgBouncer in your connection URL by adding the ?pgbouncer=true parameter (forceTransactions from the PrismaClient is now deprecated and will be removed in an upcoming release)
• Improved handling of comments in prisma format
• Various improvements to Prisma's VS Code extension (e.g. better error messages and debug information)

Fixes and improvements

prisma

• [Introspection] Better introspect success message
• DigitalOcean Postgres + PGBouncer Issues
• &sslcert=server-ca.pem in PostgreSQL connection url throw Error opening a TLS connection: One or more parameters passed to a function were not valid.
• Prisma generate --watch errors
• Introspect default value with backslashes causes problem when generating client
• Prisma DMMF parses comments as fields docs
• Cascade delete does not work unless relation is optional
• Special-case syntax error for multiple unnamed arguments in directive in the schema parser
• Error on table update using a mapped field in where clause
• Add renovate bot for dependencies
• Prisma Schema: Add .prisma syntax highlighting for Sublime Text
• Simple filtering for JSON
• Panic calling findOne with mapped unique key fields
• Validation issue for schemas with compound foreign keys
• [introspect] Expose database classification feature
• If a comment is the last line in a model, prisma format will move it out of the model
• Investigate alternatives to required PgBouncer configuration
• Overwriting database connection string in Prisma Client does not work
• PgBouncer mode
• Documentation parsed from doc comment is missing for enums

prisma-client-js

• Document forceTransactions / pgBouncer
• Better instructions on Query Engine panic
• Ability to use Heroku's pgbouncer
• Prisma Client failing with PgBouncer Transaction Mode
• Basic reporting capability for runtime errors in Client
• Prisma Client Beta 4 broken with Netlify
• PANIC error on upsert query
• Cannot use prisma.create() with nullable field set to null

vscode

• Trailing comments are broken to the next line when formatting
• Recognize Prisma1 schemas and tell user to install the other extension and rename file
• Allow inline comment
• Formatting moves comment from inside model to above model
• Preserve newlines / whitespaces inside models
• Extension deletes unused commented out models
• Use same versioning scheme & release cadence as Prisma itself
• prisma-fmt: add newline in the end of the file
• Triple slash comments in prisma schema file not working
• Versioning scheme
• Add badges and repo explanation to README
• VSCode extension errors when linting .prisma file
• Also output extension name / package and version on startup
• Configuring Git to handle line endings
• Remove Prisma as Icon Theme

prisma-engines

• Improve a model's default value in the AST

Credits

Huge thanks to @Sytten, @thankwsx, @zachasme for helping!

Today, we are issuing the fifth Beta release: 2.0.0-beta.5 (short: beta.5).

Major improvements

Support for Alpine Linux

From now on, you don't need to build your own binaries for Alpine Linux and all musl-based distros anymore. They're shipped by default with the Prisma CLI and Prisma Client.

Support for Node v14

The new Node v14 is from now on fully supported with the Prisma CLI and Prisma Client.

Fixed issues with JSON support in Prisma Client

You can now use the new Json type that was introduced in the last release also in Prisma Client.

Fixes and improvements

prisma

• Provide binaries for Alpine Linux
• Prisma create failing with query interpretation errors
• Cannot update a column value to null?
• Add syntax highlighting to more tools
• Binary targets for FreeBSD in Beta4 no longer working
• Prisma CLI is throwing segmentation fault with node 14 (fs.writeFileSync arg)

prisma-client-js

• missing FROM-clause entry for table
• Automatically serialize a non ISO date string if it is serializable by javascript date object
• Can't create record with Json

migrate

• Bug: Can't save new migration file

vscode

• Go To Definition...not going to Definition

prisma-engines

• Disallow null for certain input types
• Nested create broken

Credits

Huge thanks to @Sytten for helping!

Today, we are issuing the fourth Beta release: 2.0.0-beta.4 (short: beta.4).

Major improvements

Support for JSON types in PostgreSQL and MySQL

Prisma now supports working with JSON data with the new Json type in the Prisma data model.

Here's an overview of how it works with different Prisma tools/workflows:

Introspection

The prisma introspect command maps the following column types to Json:

• Postgres: JSON and JSONB
• MySQL: JSON

Prisma Migrate

prisma migrate uses the following data type when creating a column for a field of type Json:

• Postgres: JSONB
• MySQL: JSON

Prisma Client

Fields of type Json will be exposed as plain JavaScript objects in the Prisma Client API.

Introducing prisma format

From now on, you can run prisma format in your project, to make your schema.prisma pretty without the VSCode extension 💅

Support for Yarn workspaces

Prisma now supports Yarn workspaces 🎉

Making Prisma Client generation more robust with .prisma folder

The generation of Prisma Client into node_modules sometimes caused problems with package managers (e.g. Yarn) which would occasionally delete the generated code.

In order to make the generation more robust, Prisma Client is now generated into a folder called node_modules/.prisma. Because of the leading dot in the folder name, package managers do not touch the folder any more. This results in the following folder structure:

node_modules/
 ↪ .prisma
   ↪ client
     ↪ schema.prisma
     ↪ index.js
     ↪ index.d.ts
     ↪ query-engine-darwin
 ↪ @prisma/client (imports the generated code from `.prisma`)

Note that the generated Prisma Client code in .prisma is now imported into @prisma/client which means there is no change for how you import and use Prisma Client in your code! You can still import Prisma Client as before with:

import { PrismaClient } from '@prisma/client'

Open Prisma Studio in specific browser

The prisma studio --experimental command now accepts a --browser option to let you choose your preferred browser for Prisma Studio, e.g.:

prisma studio --browser "Google Chrome" --experimental

Here's an overview of the browser names you can use per platform (note that double quotes are required when the browser name contains space and the right capitalization is required too):

Fixes and improvements

prisma

• Data type JSON
• beta.3 (#1635) breaks custom binaries (on Alpine)
• Investigate GCR Panic
• RUST error, Did not find a relation for model UserDetail and field userid, Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
• Difficult to read error report
• Query by unique constraint missing included properties
• Update Prisma 1 docs to link to Prisma 2 docs
• introspect fails on SQLite

prisma-client-js

• Does not work with yarn workspace
• Type Generation : returned payload type on upsert not using include
• Providing null for a nullable relation results in error
• Error when setting a relation field to null

migrate

• Security issue with dependency - minimist
• cannot drop table because other objects depend on it

vscode

• Saving adds random fields to model
• Context-aware auto-completion
• Modelname being formatted as lowercase when auto-creating back relations
• Extension should report failure if formatting / binary execution fails
• Rename "Automatic Publish"
• Show error in VS Code extension when illegal model name is used
• alpha version of extension
• Multiple versions (e.g. 0.0.21 and 0.0.22) are missing Git tags
• Clickable Schema (Relations)
• Automated testing

Credits

Huge thanks to @Sytten for helping!

Today, we are issuing the third Beta release: 2.0.0-beta.3 (short: beta.3).

Major changes

• Enums are now disallowed for SQLite
• Required 1-1 self relations are forbidden now
• The prisma2 command is now deprecated in favor of prisma

Fixes and improvements

prisma

• Introspection Regression "Error validating: The argument references must refer to a unique criteria in the related model pages_language. But it is referencing the following fields that are not a unique criteria: page_id"
• Engine freezes all requests/responses in 2.0.0-beta.2
• [Beta.2] Omission of relation field causes unclear rust error message at generate
• Custom type for id
• Document AWS lambda configuration to avoid timeouts
• raw: COALESCE/IFNULL returns MA==
• Upserting Many-To-Many fails with unique index constraint
• Bad cli output
• @relation annotation's field attribute should not be able to accept scalar lists
• I am new to PRISMA /. i am not able to install via NPM .. can some body help ?
• Should we output introspection warnings to stderr when using prisma introspect --print?
• Improve Introspection warnings output for invalid names
• Deprecation wrapper for prisma2 executable
• generate does not work in folders with spaces
• Rename CLI folder
• Remove enum usage from docs where sqlite is used
• Required 1-1-self-relations should be forbidden?

prisma-client-js

• PrismaClientUnknownRequestError - InterpretationError on nested create
• Update Many in self-referencing relations

migrate

• Add ability to define schema path for prisma migrate cli to help output
• --preview is ignored when doing prisma migrate down --preview --experimental
• Migrate allows you to use enums in sqlite even though sqlite doesn't support them

vscode

• Auto formatting is adding fields which were already specified
• Using env variables breaks VS Code plugin formatting funcionality
• Error message shown in wrong location

Today, we are issuing the second Beta release: 2.0.0-beta.2 (short: beta.2).

We want to give a huge shoutout to @Sytten who helped us fix some issues in the Rust codebase 🎊

Major improvements

Parametrized count queries in Prisma Client

In previous versions of Prisma Client, it was not possible to provide any filter arguments when using .count. With this release, you can provide the same filter arguments from findMany:

const numberOfUsersCalledBob = await prisma.user.count({ where: { name: 'Bob' }})

Lots of bug fixes and improvements

With this release, we were able to fix a lot of nasty bugs like some schema validation issues in VS Code (#1989 and #1970) as well as a Prisma Migrate bug with 1-n self-relations.

Fixes and improvements per Prisma 2.0 repository

prisma

• Provide log output when .env file is used - Closes #1155
• Add MariaDB integration tests closes #1791
• Fix "because" typo in README
• Add a --json flag to version command
• Running prisma version fails
• Schemas with incomplete @relation annotations should be rejected during Client generation
• Fix prisma2 generate --watch exits when no models are defined in schema.prisma
• Fix link to Prisma documentation
• fix typo in README
• Fix "Getting started" links
• Prisma generate script throws error
• Running a built binary fails with weird error
• Validation error message for schema with missing relation scalar field (old syntax)
• Validation Error: error: Error validating: The relation field Teams uses the scalar fields tmID. The arity of those fields must be the same. The relation field is required but the scalar fields are optional.
• Add integration test for introspection warnings
• Error format for enum field declaration broken
• Error format for missing type on field is broken
• Error when disconnecting m:n relation with string-id-model
• Getting error on deeper includes
• ENV-based binary variables broken on preview022
• Proposal: Rename prisma binary to query-engine
• prisma2 generate --watch exits when no models are defined in schema.prisma
• Provide log output when .env file is used

prisma-client-js

• adjust README
• Fix a typo in the generated docs
• Error message "Error: Query engine binary for current platform "..." could not be found" could list other file from that directory to help debugging
• Fix batching. Closes #562
• Invalid include query results in unexpected output
• Query batching sends queries with different selection set
• Super long output on error in create

prisma-engines

• Adapt test-cli to new query engine binary name
• Unify duplicated test assertion code paths
• Remove Unused Dependencies
• Upgrade quaint and adjust tests after mysql floats fix
• Fix Self Relation Rendering
• Minor opportunistic simplifications in sql schema calculator
• Fix detection of 1:1 relations for self-relations
• Datamodel parser/relation arguments validation
• Downgrade tokio to 0.2.13
• Fix for unexpected additional records during deeply nested reads.
• Bug: subquery has too many columns
• Update crates (incl. faster tokio)
• cargo fmt
• adapt arity validation for relation fields to match introspection logic
• Datamodel Parser: allow dbgenerated function for enum fields
• add readonly flag to dmmf field
• Drop relations that are referring to unsupported types
• Add dmmf subcommand to test-cli
• Ignore env errors when reformatting
• Test column types with dubious nullability properties (pg/mysql)
• improve relation validations
• prisma-fmt formatting regression
• Add support for newline in the source and generator blocks
• Investigate weirdness around nullability of timestamp fields
• Proposal: Tighten datamodel parser rules for @relation
• Reenable error code and message assertions in scala tests

migrate

• Fix broken bug_report ISSUE_TEMPLATE markup
• Prisma CLI cannot revert a migration

We are extremely excited to launch the first official Beta of Prisma 2.0 today! 🎉 Along with this release, we have also published a new website and an updated Prisma 2.0 documentation. This makes Prisma 2.0 the default for developers who are getting started with Prisma.

Upgrading to the new relation syntax

If you have been using Prisma Migrate before to create your models and their relations, the new relation syntax can seem a bit counterintuitive at first. Here's a quick overview of the most important things to consider when upgrading.

Note that this only covers one-to-one and one-to-many relations. Prisma's implicit many-to-many relations are adjusted by manually adding the @relation attribute with a single field reference to both sides of the relation (most often this looks as follows: @relation(references: [id])).

Consider this sample schema from preview025:

model User {
  id      Int      @id @default(autoincrement())
  profile Profile?
  posts   Post[]
}

model Profile {
  id   Int  @id @default(autoincrement())
  user User // backed up by a foreign key called `user` in the DB   
}

model Post {
  id     Int  @id @default(autoincrement())
  author User // backed up by a foreign key called `author` in the DB   
}

CREATE TABLE "User" (
    id integer PRIMARY KEY,
    name text NOT NULL DEFAULT ''::text
);

CREATE TABLE "Profile" (
    bio text NOT NULL DEFAULT ''::text,
    id integer PRIMARY KEY,
    user integer NOT NULL,
    FOREIGN KEY ("user") REFERENCES "User"(id)
);

CREATE TABLE "Post" (
    id integer PRIMARY KEY,
    title text NOT NULL
    author integer NOT NULL,
    FOREIGN KEY ("author") REFERENCES "User"(id)
);

Note that in this case, the foreign keys in the underlying database are located on the Profile and Post tables. The User table does not have any foreign keys (which means the profile and posts relation fields on the User model are virtually maintained by Prisma).

The new syntax requires you to make the foreign key explicit in the Prisma schema (so you need to add another field in addition to the already existing relation field). This new field is your relation scalar field and directly represents the foreign key in the underlying database.

Assume you're now upgrading to 2.0.0-beta.1:

npm install @prisma/[email protected]
npm install @prisma/[email protected] --save-dev

Without touching the database, one way to adjust your Prisma schema to adhere to the new syntax would be as follows:

model User {
  id      Int      @id @default(autoincrement())
  profile Profile?
}

model Profile {
  id      Int     @id @default(autoincrement())
  user    User    @relation(fields: [userId], references: [id])
+ userId  Int     @map("user") // relation scalar field (used in the `@relation` attribute above)
}

model Post {
  id         Int         @id @default(autoincrement())
  author     User        @relation(fields: [authorId], references: [id])
+ authorId   Int         @map("author") // relation scalar field  (used in the `@relation` attribute above)
}

In this code, you introduced the userId and authorId fields on Profile and Post. These fields are your relation scalar fields and represent the foreign key in your database. But because the current foreign keys in the database are called user and author and therefore don't map directly to the model fields, you need to annotate the fields with @map to "map" them to a differently named database column.

You can then re-generate Prisma Client. Note that the prisma2 command has been renamed to prisma in 2.0.0-beta.1, so you need to invoke the generate command as follows:

npx prisma generate

Note that the new relation scalar field is currently read-only in the generated Prisma Client API. To modify the connections in youe database, you can keep using Prisma Client's nested write queries.

Breaking changes

No more Preview releases

With this release the Preview period for Prisma 2.0 ends. This means that releases will not be tagged preview any more, but with beta. Today's release is called: 2.0.0-beta.1.

Restructuring GitHub repositories

Since its initial release, the main repository for Prisma 2.0 has been called prisma2.

Because Prisma 2.0 is now the default for developers getting started with Prisma, the Prisma repositories have been renamed as follows:

• The prisma/prisma2 repository has been renamed to prisma/prisma
• The prisma/prisma repository has been renamed to prisma/prisma1

Renaming the prisma2 CLI

During the Preview period, the CLI for Prisma 2.0 was invoked using the prisma2 command. With Prisma 2.0 being the default for new developers getting started with Prisma, the command is changed to just prisma. The exising prisma command of Prisma 1 is renamed to prisma1.

Also note that the installation of the npm packages changes:

New syntax for defining relations

The Beta release introduces a new relation syntax which makes the @relation attribute required in each relation in the Prisma schema. Note that it often is enough to only declare the attribute only on the side of the relation (the side that stores the foreign key in the underlying database).

Additionally, for one-to-one and one-to-many relations, you need add a relation scalar field to the model which is used in the @relation attribute. This relation scalar field directly maps to the foreign key in the underlying database. Note that the foreign key is read-only in the Prisma Client API, to modify a relation you can keep using nested write queries as before.

Here's an overview for how relations need to be updated.

One-to-one

During the Preview period, a 1-1-relation could be defined as follows:

model User {
  id        Int       @id @default(autoincrement())
  profile   Profile
}

model Profile {
  id      Int    @id @default(autoincrement())
  user    User
}

With the new Beta, you now must determine which side should store the foreign key. You can do so by adding the @relation attribute with its corresponding relation scalar field to the model:

model User {
  id        Int       @id @default(autoincrement())
  profile   Profile
}

model Profile {
  id      Int    @id @default(autoincrement())
+ user    User   @relation(fields: [userId], references: [id])
+ userId  Int    // relation scalar field (used in the `@relation` attribute above)
}

This Prisma schema is represented as follows in SQL (the foreign key is stored on Profile):

CREATE TABLE "User" (
    id SERIAL PRIMARY KEY
);
CREATE TABLE "Profile" (
    id SERIAL PRIMARY KEY,
    "userId" INTEGER NOT NULL UNIQUE,
    FOREIGN KEY ("userId") REFERENCES "User"(id)
);

One-to-many

During the Preview period, a 1-n-relation could be defined as follows:

model User {
  id        Int      @id @default(autoincrement())
  posts     Post[]
}

model Post {
  id        Int   @id @default(autoincrement())
  author    User
}

With the new Beta, you now must add the @relation attribute and its corresponding relation scalar field to the non-list field of the relation:

model User {
  id        Int      @id @default(autoincrement())
  posts     Post[]
}

model Post {
  id        Int   @id @default(autoincrement())
+ author    User  @relation(fields: [authorId], references: [id])
+ authorId  Int
}

This Prisma schema is represented as follows in SQL:

CREATE TABLE "User" (
    id SERIAL PRIMARY KEY
);
CREATE TABLE "Post" (
    id SERIAL PRIMARY KEY,
    "authorId" integer NOT NULL,
    FOREIGN KEY ("authorId") REFERENCES "User"(id)
);

Many-to-many (implicit)

During the Preview period, a m-n-relation could be defined as follows:

model Post {
  id         Int        @id @default(autoincrement())
  categories Category[]
}

model Category {
  id    Int    @id @default(autoincrement())
  posts Post[]
}

With the new Beta, you now must add the @relation attribute to both sides of the relation:

model Post {
  id         Int        @id @default(autoincrement())
+ categories Category[] @relation(references: [id])
}

model Category {
  id    Int    @id @default(autoincrement())
+ posts Post[] @relation(references: [id])
}

Prisma will maintain the relation with the following relation table:

CREATE TABLE "Category" (
    id SERIAL PRIMARY KEY
);
CREATE TABLE "Post" (
    id SERIAL PRIMARY KEY
);
-- Relation table + indexes -------------------------------------------------------
CREATE TABLE "_CategoryToPost" (
    "A" integer NOT NULL REFERENCES "Category"(id),
    "B" integer NOT NULL REFERENCES "Post"(id)
);
CREATE UNIQUE INDEX "_CategoryToPost_AB_unique" ON "_CategoryToPost"("A" int4_ops,"B" int4_ops);
CREATE INDEX "_CategoryToPost_B_index" ON "_CategoryToPost"("B" int4_ops);

Why this change was introduced

The changes in the relation syntax were needed to enable more complex relation configurations, e.g. when using multi-field IDs.

Note that we aim to simplify the current syntax in the future again ("take one step backward, to be able to move two steps forward").

The prisma2 npm package is deprecated

The prisma2 npm package is now deprecated, the Prisma 2.0 CLI can now be installed via the @prisma/cli npm package, e.g.:

npm @prisma/cli --save-dev
npx prisma

To prevent confusions during installation, it now outputs the following when you try to install it:

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│   The package prisma2 has been renamed to @prisma/cli.      │
│                                                             │
│   Please uninstall prisma2 from your project or globally.   │
│   Then install @prisma/cli to continue using Prisma 2.0:    │
│                                                             │
│      # Uninstall old CLI                                    │
│      npm uninstall prisma2                                  │
│                                                             │
│      # Install new CLI                                      │
│      npm install @prisma/cli --save-dev                     │
│                                                             │
│      # Invoke via npx                                       │
│      npx prisma --help                                      │
│                                                             │
│   Learn more here: https://pris.ly/preview025               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Today, we are issuing the twenty-fifth Preview release: 2.0.0-preview025 (short: preview025).

Breaking changes

Renaming the prisma2 npm package

With this release, we're renaming the Prisma 2 CLI npm package from prisma2 to @prisma/cli. Note that you can still invoke the CLI using the prisma2 command!

To upgrade, you first should uninstall the current prisma2 version and then install the @prisma/cli package.

Local installation (recommended)

The local installation is generally preferred since it prevents conflicting versions of the same package.

# Uninstall current `prisma2` CLI (`preview024` or earlier)
npm uninstall prisma2

# Install new `prisma2` CLI via `@prisma/cli` npm package
npm install @prisma/cli --save-dev

# Invoke the CLI via `npx`
npx prisma2

Global installation

# Uninstall current `prisma2` CLI (`preview024` or earlier)
npm uninstall -g prisma2

# Install new `prisma2` CLI via `@prisma/cli` npm package
npm install -g @prisma/cli

# Invoke the CLI via `npx`
npx prisma2

Other

• The prisma2 --version output changed
• Virtual relation fields (aka “back-relation fields”) follow the same name as the model they relate to during introspection
• The default for errorFormat in the PrismaClient constructor now is colorless

Fixes and improvements per Prisma 2 repository

prisma2

• feat(prisma2/cli): allow arbitrary generator commands with flags
• Update docs to reflect existing examples
• Comments in schema's datasource block fail with Error: Schema parsing error: Unexpected token. Expected one of: End of block ("}"), alphanumeric identifier
• get-config gets the datamodel from the env vars
• Relation table for implicit m:n-relation not recognized by introspection
• update postgres integration tests
• [Introspection] error: Argument 'value' is missing in attribute '@default'.
• add instructions for adding bug reports
• Investigate if we can hide GraphQL Playground on CSB
• Remove AUMFIDARR guardrails
• Failed to validate the query Error occurred during query validation & transformation:
• PostgreSQL: "incorrect binary data format in bind parameter x"
• [Introspection] Comment out all unsupported column types
• MySQL: "DateTime value not stored as DateTime, Int or string"
• sqlite/chinook returns PANIC: Could not parse stored DateTime string: 2009-01-01 00:00:00: ParseError(Invalid) on findMany()
• AWS Lambda timed out
• Don't expose GraphQL Playground
• [Introspection] Guardrail: Remove default values we do not support
• [Introspection] Relation guardrail creates duplicate fields
• [Introspection] Decide on a way forward for introspection of types our internal type system currently cannot represent
• Schema Validation fails with panic thread 'main' panicked at 'Expected ID field ... to be present on the model'
• Remove opinionated casing for back relation field names
• Unclear rust error PANIC
• "Oops. We could not send the error report."
• [Introspection] "The model 'x' cannot be defined because a model with that name already exists."
• [Introspection] Crashes when default value contains line breaks
• Expand --version command
• [Introspection] "created_at timestamp with time zone not null default now()" doesn't work
• [Introspection] ID = (Scalar, RelationField)
• Explicit many to many relationships with/without extra columns
• @default doesnt work for enum

prisma-client-js

• Fix .raw with parameters for PostgreSQL
• Using raw queries with tagged template literals doesn't include parameters
• Fix downloading HTTPS file with HTTP proxy
• Change default error formatting from pretty to colorless
• Some models return Error parsing GraphQL query: query parse error: Parse error at 4:3 Unexpected}[Punctuator]ExpectedName from findMany({}) after introspection
• Can't query models without scalar fields
• prisma2 generate always uses yarn even if you're using NPM in your project
• Cannot find module '@prisma/client' after installing a new package via NPM
• Mutating a Float sometimes results on sightly different value written to Postgres
• Export the current Prisma version
• Using a relation as @id or in @@unique doesn't work
• Some models return undefined from findMany({}) after introspection
• 3 way join with @@id failing when querying
• find by composite primary keys API is super weird
• Can't findOne, update, delete on composite primary keys
• Find by a null time doesn't work
• Find with exact DateTime input doesn't work with findMany or findOne
• Gracefully handle incorrect id column type
• Nested writes don't work on 3rd level with required relation

prisma-engines

• [WIP] new @relation validations
• Fix unused value warning in test
• Set the pool constraints in QE
• Health check fixes
• Test unique fields as ID on postgres
• New relations in the migration engine
• [WIP] IE Changes
• Unify dml error handling
• Test postgres array defaults
• Make dmmf dm errors more beautiful
• Schema validation errors broken since alpha 940
• Citext
• The dmmf cli cmd should not crash for env vars
• Test and fix postgres default handling
• Remove the camelcasing for backrelation fields
• Set all datamodel-related flags in structopt
• Add an introspect subcommand to test-cli
• Test mysql defaults
• Adjust legacy M:N Relation Inference
• Test all identifier types on mysql
• Disable playground by default, flag for enabling
• Test postgres exotic filters
• Discriminate between unsupported types and those that cast to string
• Comment out Unsupported Datatypes
• Avoid unecessary allocation in quaint query building
• Recognize all Prisma 1.0 relations as Implicit Many2Many relations
• Postgres exotic filters
• Do not SELECT 1 before every query
• Test new supported column types
• Adapt ME tests to new defaults handling
• QE: Batch huge IN queries into smaller batches
• Remove logic for dropping relations when they are part of the ID
• Batch big IN/NOT IN selections
• fix(errors): move some errors back in spec
• QE: Optimize the compound id select
• [WIP] Introduce dbGenerated() for Default values
• Extend Benchmarking Suite
• Query Engine: SQL connector must use chunking when a large number of prisma-engines is reached
• Reduce cloning in nested read
• Make implicit relation rules explicit with prisma-fmt

migrate

• prisma2 migrate causes SIGSEGV segfault

Today, we are issuing the twenty-fourth Preview release: 2.0.0-preview024 (short: preview024).

Major improvements

Reduced size of Prisma Client & Azure functions support

This release contains major improvements for Prisma Client. It now supports Windows Azure functions. In addition to that, the generated Prisma Client code inside your node_modules directory now is a lot smaller.

Another improvement is a better debugging experience. When setting the DEBUG environment variable (e.g. with export DEBUG="*"), the logging output now contains the names of Prisma Client API calls.

Use relation fields as ID on a Prisma model

In this release, it's now possible to use relation fields of Prisma models as IDs. In "database-speak", this means that you can now have both a primary key and a foreign key constraint on the same column.

Reference a single-field ID

For example, a Movie could always be identified by its Director:

model Movie {
  director Director @id
  title    String
}

model Director {
  id Int @id @default(@autoincrement())
  name String
}

This is what the corresponding SQL (in SQLite dialect) looks like:

CREATE TABLE "Movie" (
    "director" INTEGER NOT NULL  ,
    "title" TEXT NOT NULL DEFAULT '' ,
    PRIMARY KEY ("director"),
    FOREIGN KEY ("director") REFERENCES "Director"("id")
);

CREATE TABLE "Director" (
    "id" INTEGER NOT NULL  PRIMARY KEY AUTOINCREMENT,
    "name" TEXT NOT NULL DEFAULT '' 
);

Nested write to create Movie with Director:

// Run inside `async` function
const movie = await prisma.movie.create({
  data: {
    title: "Hello World",
    director: {
      create: {
        name: "Alice"
      }
    }
  },
})

Nested write to create Director with Movie:

// Run inside `async` function
const director = await prisma.director.create({
  data: {
    name: "Bob",
    movies: {
      create: [{
        title: "Hello World"
      }]
    }
  },
})

Reference a multi-field ID

You can also create a relation to a multi-field ID:

model Movie {
  director Director @id @map(["firstName", "lastName"]) 
  title    String
}

model Director {
  firstName   String
  lastName    String

  @@id([firstName, lastName])
}

Note that in this case, the Movie table in the underlying database will actually have two physical columns called firstName and lastName. These are referencing the respective firstName and lastName column on the Director table.

Here is what the above models correspond to in SQL:

CREATE TABLE "Movie" (
    "firstName" TEXT NOT NULL  ,
    "lastName" TEXT NOT NULL  ,
    "title" TEXT NOT NULL DEFAULT '' ,
    PRIMARY KEY ("firstName","lastName"),
    FOREIGN KEY ("firstName","lastName") REFERENCES "Director"("firstName","lastName") 
);

CREATE TABLE "Director" (
    "firstName" TEXT NOT NULL DEFAULT '' ,
    "lastName" TEXT NOT NULL DEFAULT '' ,
    PRIMARY KEY ("firstName","lastName")
);

In many cases, it might make sense to name the columns on Movie differently. For example, they could be called directorFirstName and directorLastName. This can be achieved via adding the @map attribute to the field:

model Movie {
  director Director @id @map(["directorFirstName", "directorLastName"]) @relation(references: [firstName, lastName])
  title    String
}

model Director {
  firstName   String
  lastName    String

  @@id([firstName, lastName])
}

Note that in this case you could also omit the @relation attribute, the result would be the same:

model Movie {
  director Director @id @map(["directorFirstName", "directorLastName"])
  title    String
}

model Director {
  firstName   String
  lastName    String

  @@id([firstName, lastName])
}

In this case, the field names in @map on Movie get matched with the field names in @@id on Director.

Both cases correspond to the following SQL:

CREATE TABLE "Movie" (
    "directorFirstName" TEXT NOT NULL  ,
    "directorLastName" TEXT NOT NULL  ,
    "title" TEXT NOT NULL DEFAULT '' ,
    PRIMARY KEY ("directorFirstName","directorLastName"),
    FOREIGN KEY ("directorFirstName","directorLastName") REFERENCES "Director"("firstName","lastName")
);

CREATE TABLE "Director" (
    "firstName" TEXT NOT NULL DEFAULT '' ,
    "lastName" TEXT NOT NULL DEFAULT '' ,
    PRIMARY KEY ("firstName","lastName")
);

Nested write to create Movie with Director:

// Run inside `async` function
const movie = await prisma.movie.create({
  data: {
    title: 'Hello World',
    director: {
      create: {
        firstName: 'Alice',
        lastName: 'Allen',
      },
    },
  },
})

Nested write to create Director with Movie:

// Run inside `async` function
const director = await prisma.director.create({
  data: {
    firstName: 'Bob',
    lastName: 'Nolan',
    movies: {
      create: [
        {
          title: 'Hello World',
        },
      ],
    },
  },
})

Multi-field ID with a relation field (which targets a model with a single-field ID)

You can also create a multi-field ID on a model that contains a relation field:

model Movie {
  director Director
  title    String

  @@id([director, title])
}

model Director {
  id   String @id @default(cuid())
  name String
}

This corresponds to the following SQL:

CREATE TABLE "Movie" (
    "director" TEXT NOT NULL  ,
    "title" TEXT NOT NULL DEFAULT '' ,
    PRIMARY KEY ("director","title"),
    FOREIGN KEY ("director") REFERENCES "Director"("id")
);

CREATE TABLE "Director" (
    "id" TEXT NOT NULL  ,
    "name" TEXT NOT NULL DEFAULT '' ,
    PRIMARY KEY ("id")
);

Nested write to create Movie with Director:

// Run inside `async` function
const movie = await prisma.movie.create({
  data: {
    title: 'Hello World',
    director: {
      create: {
        name: 'Alice',
      },
    },
  },
})

Nested write to create Director with Movie:

// Run inside `async` function
const director = await prisma.director.create({
  data: {
    name: 'Bob',
    movies: {
      create: [
        {
          title: 'Hello World 2',
        },
      ],
    },
  },
})

Multi-field ID with a relation field (which targets a model with a multi-field ID)

You can also define a multi-field ID on a model which contains a relation field that targets a model with a multi-field ID:

model Movie {
  director Director
  title    String

  @@id([director, title])
}

model Director {
  firstName String
  lastName  String

  @@id([firstName, lastName])
}

This is what the above code translates to in SQL:

CREATE TABLE "Movie" (
    "director_firstName" TEXT NOT NULL  ,
    "director_lastName" TEXT NOT NULL  ,
    "title" TEXT NOT NULL DEFAULT '' ,
    PRIMARY KEY ("director_firstName","director_lastName","title"),
    FOREIGN KEY ("director_firstName","director_lastName") REFERENCES "Director"("firstName","lastName") 
);

CREATE TABLE "Director" (
    "firstName" TEXT NOT NULL DEFAULT '' ,
    "lastName" TEXT NOT NULL DEFAULT '' ,
    PRIMARY KEY ("firstName","lastName")
);

Similar to the case before, you can also give names to the added columns on Movie by using the @map attributed:

model Movie {
  director Director @map(["directorFirstName", "directorLastName"]) @relation(references: [firstName, lastName])
  title    String

  @@id([director, title])
}

model Director {
  firstName String
  lastName  String

  @@id([firstName, lastName])
}

And as before you can also omit the @relation attribute in this scenario:

model Movie {
  director Director @map(["directorFirstName", "directorLastName"])
  title    String

  @@id([director, title])
}

model Director {
  firstName String
  lastName  String

  @@id([firstName, lastName])
}

In both cases, the models correspond to the following tables:

CREATE TABLE "Movie" (
    "directorFirstName" TEXT NOT NULL  ,
    "directorLastName" TEXT NOT NULL  ,
    "title" TEXT NOT NULL DEFAULT '' ,
    PRIMARY KEY ("directorFirstName","directorLastName","title"),
    FOREIGN KEY ("directorFirstName","directorLastName") REFERENCES "Director"("firstName","lastName")
);

CREATE TABLE "Director" (
    "firstName" TEXT NOT NULL DEFAULT '' ,
    "lastName" TEXT NOT NULL DEFAULT '' ,
    PRIMARY KEY ("firstName","lastName")
);

Nested write to create Movie with Director:

// Run inside `async` function
const movie = await prisma.movie.create({
  data: {
    title: 'Hello World',
    director: {
      create: {
        firstName: 'Alice',
        lastName: 'Allen',
      },
    },
  },
})

Nested write to create Director with Movie:

// Run inside `async` function
const director = await prisma.director.create({
  data: {
    firstName: 'Bob',
    lastName: 'Nolan',
    movies: {
      create: [
        {
          title: 'Hello World',
        },
      ],
    },
  },
})

Breaking changes

MODELGetSelectPayload and MODELGetIncludePayload have been merged into MODELGetPayload. More info here.

Fixes and improvements per Prisma 2 repository

prisma2

• fix(#1728) Handle disconnected error for introspection engine
• Better handling of introspect crash
• [Introspection] Remove type annotation from Postgres default in cases other than Text
• Integration tests: SQLite
• Integration tests: MySQL
• Introspection composite foreign keys pointing to composite primary keys
• Prisma doesn't work on Azure windows functions
• [Introspection] Postgres @default include type information
• Invalid response data: the query result was required, but an empty Object((Weak)) was returned instead (drupal)
• Introspection bug for @@unique name on MySQL
• Integration tests for SQLite and MySQL
• Put @prisma/sdk version in lockstep with prisma2
• introspect for SQLite returns id as String when it should be Int
• Update docs about PostgreSQL socket
• Document logging options (via DEBUG env var)
• Kebab-case parameters due to a change in QE/IE/ME

migrate

• Kebab-case-parameters in ME

prisma-client-js

• Reduce size of generated client
• Print query parameters
• Nested create broken in latest alpha
• Query engine generates wrong SQL queries for Hierarchical Data
• Log all Prisma Client method executions
• Switching to kebab-case on QE/ME/IE params
• Change docs about PostgreSQL socket connection

prisma-engines

• Comment out fields with empty names
• Allow Default Values for Enums that look like Booleans
• Postgres Default Values
• Test and fix mapping of mysql and postgres native types
• Start Adding Test Cases for Using a Relation or Parts of it as Primary Key
• Fix prisma-engines#567
• Fix @unique on composite relation fields
• Better way to query with many compound ids
• ME: Indices to composite foreign keys are impossible to create
• Update README with proper cargo test command
• Return a more intelligible error on unexpectedly empty response
• improve nested pagination from O(n log n) to O(n)
• optimize m2m join with in clause
• Index join tables on the B side
• Make foreign key fields cascade on delete by default
• Test and fix Id as part of relation in migration engine
• ME: Many-to-many table indices sub-optimal
• Recognize int as Integer on Sqlite
• Unify cli input parsing
• Remove From DMMF

Today, we are issuing the twenty-third Preview release: 2.0.0-preview023 (short: preview023).

This release contains breaking changes, be sure to read the notes below before upgrading!

Breaking changes

Cursor-pagination API changed in Prisma Client

Because Prisma now supports composite unique constraints, the before and after API for cursor-pagination (which is based on unique fields) also changes. The cursor is now wrapped in an object which might have multiple fields.

Assume you have this Prisma model:

model Post {
  id        Int     @default(autoincrement())
  title     String  @unique
  content   String?
}

Before

const cursor = 42
const posts = await prisma.post.findMany({
  after: cursor
})

After

const cursor = 42
const posts = await prisma.post.findMany({
  after: { id: cursor }
})

Removed the enabled property in datasource blocks

The enabled property was removed from the datasource blocks.

Major improvements

In this issue, we're lifting a major limitation of Prisma which always required every model to have exactly one primary key constraint. In the Prisma schema, this primary key was represented using the @id attribute.

With this release, you can now have tables:

• without primary keys (but unique constraints)
• with composite primary keys
• with composite unique constraints

Read below for more information on each of these new features. Lifting these limitations was a major effort, please be sure to report any bugs or other issues you encounter using these new features!

Allows models without IDs

In previous Prisma versions, there was a hard requirement that every model in your Prisma schema needed to have a single @id field (which maps to a primary key constraint in the underlying database). This requirement is now lifted and your models don't need primary key constraints any more to be compatible with Prisma 2 (they do need at least one unique constraint though).

For example, this data model is now valid:

model Post {
  title     String  @unique
  content   String?
  published Boolean @default(false)
  author    User?
}

model User {
  email String  @unique
  name  String?
  posts Post[]
}

Composite primary keys

As of this release, Prisma supports composite IDs (which map to multi-column primary key constraints in the underlying database). Composite IDs are defined on a "model-level" using the @@id attribute. Here's an example:

model User {
  firstName String
  lastName  String
  email     String

  @@id([firstName, lastName])
}

This also impacts the Prisma Client API and how you're querying for single records, e.g. in findOne, update or delete queries where you need to identify a record by its primary key (or another unique field). These queries take the following type as input:

export type UserWhereUniqueInput = {
  firstName_lastName?: FirstNameLastNameCompoundUniqueInput | null
}

export type FirstNameLastNameCompoundUniqueInput = {
  firstName: string
  lastName: string
}

This means, in order to query for a User record, you need to provide both firstName and lastName fields wrapped inside a firstName_lastName object:

const user = await prisma.user.findOne({
  where: {
    firstName_lastName: {
      firstName: "Jane",
      lastName: "Doe"
    }
  }
})

Composite unique indexes / constraints

As of this release, Prisma also supports composite unique constraints (which map to multi-column unique constraints in the underlying database). Composite unique constraints are defined on a "model-level" using the @@unique attribute.

Note: Primary key and unique constraints are very similar but have some differences on the database-level. You can learn more about the differences here.

Here's an example:

model User {
  firstName String
  lastName  String
  email     String

  @@unique([firstName, lastName])
}

This also impacts the Prisma Client API and how you're querying for single records, e.g. in findOne, update or delete queries where you need to identify a record by its primary key (or another unique field). These queries take the following type as input:

export type UserWhereUniqueInput = {
  firstName_lastName?: FirstNameLastNameCompoundUniqueInput | null
}

export type FirstNameLastNameCompoundUniqueInput = {
  firstName: string
  lastName: string
}

This means, in order to query for a User record, you need to provide both firstName and lastName fields wrapped inside a firstName_lastName object:

const user = await prisma.user.findOne({
  where: {
    firstName_lastName: {
      firstName: "Jane",
      lastName: "Doe"
    }
  }
})

Introspection now recognizes default constraints

Prisma's introspection now reconized DEFAULT constraints that are defined on a column. These constraints are represented in the generated Prisma schema using the @default attribute.

Optimize nested GraphQL queries that use Prisma Client ("dataloader")

When building a GraphQL server with Prisma Client, it wasn't easy to avoid the n+1 problem with nested queries. This release of Prisma Client optimizes the execution of GraphQL nested queries by batching requests against the database.

Fixes and improvements per Prisma 2 repository

prisma2

• Add @prisma/studio-types to prisma2 devDependencies
• generate --watch broken
• Error: [/rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libcore/macros/mod.rs:15:40] called Option::unwrap() on a None value
• Add docs for .raw template literal API with parameters #1583
• Unclear rust error: called Option::unwrap() on a None value
• [Introspection] Order of fields in @@index changes with alpha 808 for PostgreSQL
• add error formatting docs
• add docs for utility types
• remove mentions of mongodb
• Remove MongoDB from documentation
• Document SQLite connection strings
• Error: P4001 The introspected database was empty: undefined url or file if sqlite should be displayed instead of undefined
• Clean up branches
• Document MySQL unix socket connection usage
• Error: Schema parsing thread 'main' panicked at 'assertion failed: (left == right)
• [Introspection] "Error: Schema parsing thread 'main' panicked at 'Encountered impossible datamodel declaration during parsing: "
• [Introspection] Postgres serial type is missing @default(autoincrement())
• Document workarounds for No-identifier-tables
• Improve .raw template literal API with parameters
• Document error formatting
• --experimental flag order
• generate shows "Downloading ..." every time when a custom binaryTarget is specified
• [Introspection] Investigate field/model types
• Remove enabled field from datasource block
• Query Engine failed ENOENT
• Certificate identity files are required in both prisma folder and in the folder from which lift is executed
• Do not require environment variables for generate
• Prisma is not including columns of Postgres type 'time without time zone' in schema

prisma-client-js

• Improve reserved words / denylist for code generation
• Implement new # private fields for PrismaClient
• Lowercasing of model and field names
• .raw template literal API with parameters
• JSON.parse(dmmfString) fails on prisma schema with docs
• Fix Error's meta property typing
• improve download logic
• Test Prisma Client with pgBouncer
• "Note, that by providing native, Prisma Client automatically resolves rhel-openssl-1.0.x"
• Better runtime error handling for missing binaries
• Document utility types
• File name (datamodel.mdl) and client name (Photon JS) in graphic in README need to be updated
• Hide top-level client properties (as they are visible via JS code intellisense)
• tslint: Invalid 'await' of a non-Promise value

prisma-engines

• [Query Core] Housekeeping
• DMMF: add information about multi field uniques
• do not fail on missing env vars in dmmf
• Only build relevant binaries in connector-test-kit
• Return a known error on invalid/absent database string
• Fix crash on building of foreign keys overlapping with PK
• Panic for empty env var
• Implementing execute raw tests in rust
• Temporarily Drop Relations on Compound Ids
• Test explicit enum default migrations with @map
• Any Relation References
• Remove lazy-static
• Fix postgres field ordering inside indexes in sql schema describer
• Test index fields ordering is preserved in postgres sql-schema-describer
• Take @map into account when migrating enum values
• Implement diffing of enum value directives
• Introspect Serial as Autoincrement on Postgres
• Optimize the amount of queries sent by sql-schema-describer on postgres
• Propagate quaint timeout messages to introspection connector errors
• Optimized Postgres Introspection
• Add rule for doc-comments to data model Parser
• Find one optimization
• Do not add @map to virtual back relation fields
• Remap Invalid Enum Values
• Single-field @@unique is not handled correctly.
• EPIC: @relation(references: ..) for multiple fields
• Query Engine: Loosen id requirement. At least one unique criteria is enough.
• EPIC: Loosen id requirement. At least one unique criteria is enough.

Today, we are issuing the twenty-second Preview release: 2.0.0-preview022 (short: preview022).

This release contains breaking changes, be sure to read the notes below before upgrading!

Major improvements

• Send raw SQL queries using prisma.raw(sql) (read the API docs)
• Stopped shipping TypeScript with Prisma Client JS
• Various introspection improvements
• prisma2 init now uses environment variables and creates a .env file

Breaking changes

Remove pluralization of virtual back-relation fields

The following change is only breaking if you're using introspection and are currently using Prisma Client API calls that are referencing a virtual back-relation field. Read on to learn more.

When introspecting a table with a foreign key, Prisma automatically creates a "virtual back-relation" field on the respective Prisma model. Consider the following SQL schema:

CREATE TABLE User (
	user_id SERIAL PRIMARY KEY NOT NULL,
	name VARCHAR(256),
);

CREATE TABLE Post (
	post_id SERIAL PRIMARY KEY NOT NULL,
	title VARCHAR(256) NOT NULL,
	author_id INTEGER,
	FOREIGN KEY (author_id) REFERENCES User(user_id) 
);

In previous Prisma 2 preview versions, the resulting Prisma data model after introspection used to be:

model User {
	user_id Int     @id @default(autoincrement())
	posts   Post[]  // before `preview022`
}

model Post {
	post_id Int     @id @default(autoincrement())
	title   String
	author  User?
}

Notice the posts field which has been added by Prisma. This field does not exist as a column on the database-level, but is a "virtual back-relation" field in the Prisma schema.

With preview022, the pluralization of the virtual back-relation field has been removed. The new introspection result would be:

model User {
	user_id Int     @id @default(autoincrement())
	post    Post[]  // after `preview022`
}

model Post {
	post_id Int     @id @default(autoincrement())
	title   String
	author  User?
}

Path for default .env file changed

As explained in this issue, the path to the default .env file is changed in this Preview version. Before, the Prisma CLI automatically loaded the environment variables from a .env file in the current working directory. This now changes and it only loads them from the directory that contains the schema.prisma file.

Enums are now handled natively (Prisma Migrate)

Enums in the Prisma schema are now mapped to enums in the underlying database (previously they were represented as strings). This means enum support for SQLite is completely removed since SQLite doesn't support enums.

Fixes and improvements per Prisma 2 repository

prisma2

• Implement changes from CLI spec
• Environment variable not found on latest alpha release
• warning In order to use "@prisma/client", please install prisma2. You can install it with "npm add -D prisma2" is printed even when prisma2 is installed
• Fetch binaries from domain instead of direct s3 url
• Implement new init flow spec
• [Introspection] Change work distribution between CLI and Introspection Engine
• Document .raw API
• Download prints many empty lines
• Improve DX about --experimental CLI commands
• Use anonymous machine token from checkpoint for error reporting
• @prisma/client@x is not compatible with prisma2@y. Their versions need to be equal., generates anyway
• Introspection: Don't execute getDatabaseDescription if error consent screen didn't have confirmation
• Only support .env file next to schema.prisma
• [Introspection] No ID: Why does it sometimes error and sometimes panic?
• [Introspection] @@id refers to original field name instead of @map-ped one
• Introspection Error Reporting does not output report ID
• introspect: "Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed"
• MySQL datamodel not matching prisma2 introspect generated schema
• generate: "Error: Schema parsing --- thread 'main' has overflowed its stack"
• Native Enums only
• [Introspection] Investigate and improve introspection speed
• Improve error when id is a String in the schema but an Integer in SQLite.
• Make using DATABASE_URL as default DB connection URL a best practice
• Init flow should default to using environment variables for connection URLs
• Create "Getting started" escape hatch for non-existent databases
• Change default schema.prisma
• Migration guide missing from Getting Started
• Improve SSL connection docs
• Empty Introspection result could lead to much nicer error message and explanation
• Supply a custom path to Prisma schema file for CLI commands (i.e. --schema?)
• Improve introspect command, backup behavior
• Unclear Introspection error message: Error parsing attribute "@id": Fields that are marked as id must be required.
• [Introspection] Additionally output count of error at end of validation output
• [Introspection] Better handling of "Error: Empty introspection result for ..."
• [Introspection] "error: Field 'x' is already defined on model 'y'.", relation name clashes
• [Introspection] "No id field defined!" should not panic and crash, but just output an error
• [Introspection] posts are turned into postses
• [Introspection] Panic "No id field defined!" (caused by: no id at all)
• Inconsistent engine files names
• Introspection tells me ⠋ Introspecting MySQL schema with 1 tables. during introspection
• Upsert causes random self-referencing 1:1 relations to break

prisma-client-js

• SQLite: Tokio stack overflow for a lot of data
• Remove compatibility plural api
• Unclear error when we guess a binary
• Execute raw is failing when template literal span over multiple lines.
• Cannot read property 'plural' of undefined at PrismaClientClass.get jsDoc
• Implement nextTick - based batching
• Postinstall: undefined and Error
• generate tells me to install wrong Prisma Client package
• Add JSDoc to top-level argument types
• .raw(...) query
• Prisma Client should pick up required env vars from .env file during development
• Make "unnecessary" client properties private
• Database restart not handled gracefully
• AWS LAMBDA - Invalid photon.() EROFS: read-only file system, chmod '/var/task/.../query-engine-rhel-openssl-1.0.x'
• Duplicate null in ENUM filters
• Stub types should be included in the released package
• UUID joins not working after 0.20 upgrade
• Document Timeouts in Prisma Client for high parallel usage
• Do not mutate exports.dmmf in generated Prisma Client
• Stop shipping TypeScript
• Expose a utility TS type to be able to extract the return type for model expressions with includes
• Bad enum naming cause Prisma Client generation error in index.d.ts
• Bundlers and binary as static assets

migrate

• Wrong name in error message
• --help does not need --experimental for main migrate, does for migrate save

prisma-engines

• Test that tables without primary key can be created
• Rename repository to prisma-engines
• UUID ID fields cause serialization to fail
• Support MariaDB in the migration and introspection engines

Today, we are issuing the twenty-first Preview release: 2.0.0-preview021 (short: preview021).

This release contains breaking changes, be sure to read the notes below before upgrading!

⚠️ If you're using Prisma together with GraphQL Nexus and nexus-prisma, check out the additional release notes of nexus-prisma: https://github.com/prisma-labs/nexus-prisma/releases/tag/0.9.0

Breaking changes

The property on the PrismaClient that exposes CRUD operations per model used to be lowercased and pluralized, the pluralization of that property is now removed.

For example, for a model User you'd access a CRUD operation via the generated prisma.users property, as in prisma.users.findMany(). As of preview021, the pluralization has been removed and the property is called after the model (but lowercased), so it would now be prisma.user.findMany().

Here are few more examples showing how the calls to your PrismaClient instance must be adjusted:

Prisma schema

model User {
  id    Int    @id @default(autoincrement())
  name  String
}

Generated Prisma Client API

const prisma = new PrismaClient()

// CRUD operations are exposed via:
- // prisma.users
+ // prisma.user

// findMany
- const users = await prisma.users.findMany()
+ const users = await prisma.user.findMany()

// findOne
- const user = await prisma.users.findOne({ where: { id: 1 }})
+ const user = await prisma.user.findOne({ where: { id: 1 }})

// create
- const user = await prisma.users.create({ data: { name: "Alice" }})
+ const user = await prisma.user.create({ data: { name: "Alice" }})

// and so on ... 

Improvements

Besides many small fixes, Prisma Client JS now uses JSDoc to bring API documentation to your fingertips as you write code in your editor:

Fixes and improvements per Prisma 2 repository

prisma2

• Broken pris.ly links in initial schema
• ExperimentalWarning: The fs.promises API is experimental message in CLI
• Api naming issue
• generate: Error message when there are no models
• Error in migration engine - Cannot start a runtime from within a runtime.
• Change generate --help message to Generate artifacts (e.g. Prisma Client)
• Adjust Prisma tagline in CLI to Prisma is a modern DB toolkit to query, migrate and model your database
• Remove prisma2 migrate docs
• Detect if unicode character can be rendered in CLI output before printing it
• undefined in prisma2 init --help output
• Remove documenation about onDelete
• Error in migration engine - no current timer when using prisma2 migrate
• Introspection Error reporting does not exit on Windows
• Improve formatting of missing generator error message
• Handle errors in prisma introspect
• Small docs issue/question @createdAt attribute
• Supress downloads when custom binary via environment variable is used
• Improve error message when OpenSSL is missing
• Introspection: autoincrement not recognized on SERIAL field
• [Introspection] Different order of ENUMs when introspecting Postgres DB
• Add an example with Prisma and Apollo Server in plain GraphQL without Nexus
• prisma2 init fails in Yarn Workspaces
• Prisma2 dev crash : thread 'main' panicked at 'Unable to resolve scalar field'
• Error with Prisma v18.2: can't find schema.prisma
• Inconsistent type generation for default values
• Each project using Prisma (and its query engine runtime) gets its own Firewall request

prisma-client-js

• Prisma client dmmf emits enum fields as scalar type
• Wrong error message when invoking findOne without args
• Remove pluralization
• Document that you can not do select in include
• Usage with pg-bouncer
• Photon crashes when set for scalarList is not provided or it is set to []
• Improve connection error message to PostgreSQL database
• Cannot read property 'collectErrors' of null
• postinstall script of this package fails if using env var in my schema
• Wrong suggestions for relations
• Name collision with identical relational property names on separate types that refer to a common type

migrate

• Typo in message after "prisma2 migrate up --experimental" command
• Unexpected error occured when running migrate up in latest alpha.
• CLI: Reorder the help output of migrate to be save, up, down (instead of save, down, up)

prisma-engine

• Expose SQLSchema RPC Call for Debugging
• Sql Introspection Connector must handle @default(autoincrement())
• Introspection Engine: Disable verbose logging
• Implement @map for relation fields that use compound references
• Error wording: Use "Prisma schema" instead of hardcoded "schema.prisma"
• Error P1006: Say "query engine binary" instead of "Photon binary"
• Error message for SQLite shouldn't mention DB server