@prisma/client

Today, we are issuing the 2.29.1 patch release.

Fixes

Prisma Client

• Cannot find namespace 'debug' in 2.29.0
• Interactive transactions not working with $queryRaw and $executeRaw in 2.29.0
• Calling .catch() or .finally() on a prisma client model query does not fire the request in 2.29.0

Today, we are excited to share the 2.29.0 stable release 🎉

🌟 Help us spread the word about Prisma by starring the repo or tweeting about the release. 🌟

Major improvements & new features

Interactive Transactions are now in Preview

Today we’re introducing Interactive Transactions – one of our most debated feature requests.

Interactive Transactions are a double-edged sword. While they allow you to ignore a class of errors that could otherwise occur with concurrent database access, they impose constraints on performance and scalability.

While we believe there are better alternative approaches, we certainly want to ensure people who absolutely need them have the option available.

You can opt-in to Interactive Transactions by setting the interactiveTransactions preview feature in your Prisma Schema:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["interactiveTransactions"]
}

Note that the interactive transactions API does not support controlling isolation levels or locking for now.

You can find out more about implementing use cases with transactions in the docs, and share your feedback.

Named Constraints are now in Preview

Named Constraints allow you to represent (when using introspection) and specify (when using Prisma Migrate) the names of constraints of the underlying database schema in your Prisma schema.

Before this release, you could only specify the underlying database constraint names for @@unique and @@index. This meant that you didn't have control over all constraint names in the database schema. In projects that adopted Prisma with introspection, some constraint names from the database were not represented in the Prisma schema. This could lead to the database schema across environments getting out of sync when one environment was introspected, and another was created with Prisma Migrate and had different constraint names.

Starting with this release, you can specify the underlying database constraint names for @id, @@id, @unique, and @relation constraints.

You can opt-in to Named Constraints by adding the namedConstraints preview feature to your Prisma Schema:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["namedConstraints"]
}

After enabling the namedConstraints preview flag, you can specify the names of constraints in the database schema using the map attribute:

• @id(map: "custom_primary_key_constraint_name")
• @@id([field1, field2], map: "custom_compound_primary_key_name")
• @unique(map: "custom_unique_constraint_name")
• @@unique([field1, field2], map: "custom_compound_unique_constraint_name")
• @@index([field1, field2], map: "custom_index_name")
• @relation(fields: [fieldId], references: [id], map: "custom_foreign_key_name")

After specifying the map attribute, Prisma Migrate will use it when creating migrations.

When using prisma db pull with namedConstraints, these names will be automatically populated in your Prisma schema unless they match our default naming convention (which follows the Postgres convention). When handwriting a Prisma schema, these names are optional and will alternatively be filled with the default names by Prisma under the hood.

The name argument in @@unique and @@id

In addition to the map argument, the @@unique and the @@id attributes have the name argument (optional) that Prisma uses to generate the WhereUnique argument in the Prisma Client API.

Note: You can use both name and map together, e.g. @@unique([firstName, lastName], name: "NameOfWhereUniqueArg", map: "NameOfUniqueConstraintInDB")

For example, given the following model:

model User {
  firstName String
  lastName  String

  @@id([firstName, lastName])
}

The following Prisma Client query is valid:

const user = await prisma.user.findUnique({
  where: {
    // firstName_lastName is the default `name`
    firstName_lastName: {
      firstName: 'Ada',
      lastName: 'Lovelace',
    },
  },
})

By adding the name argument to the @@id attribute:

model User {
  firstName String
  lastName  String

-  @@id([firstName, lastName])
+  @@id([firstName, lastName], name: "fullname")
}

The following query is valid:

const user = await prisma.user.findUnique({
  where: {
    // fullname comes from the name argument
    fullname: {
      firstName: 'Ada',
      lastName: 'Lovelace',
    },
  },
})

Note: For the @@unique attribute this functionality was already available in previous releases. For @@id this is new.

---

You can learn more about namedConstraints in our documentation.

Please check our upgrade guide before enabling the preview flag and running migrate operations for the first time. It explains what to do if you either want to keep the existing names in your database or want to switch to the default names for a cleaner Prisma schema.

Prisma Adopts Semantic Versioning (SemVer)

As previously announced, we are adjusting our release policy to adhere more strictly to Semantic Versioning.

In the future, breaking changes in the stable development surface i.e. General Availability will only be rolled out with major version increments.

You can learn more about the change in the announcement blog post.

Fixes and improvements

Prisma Client

• API for interactive transactions with dependencies between write-operations
• [SQL Server] add validation for disallowed relationships (e.g. cyclic)
• The incoming request has too many parameters. The server supports a maximum of 2100 parameters. Reduce the number of parameters and resend the request.
• Transaction with bad input should rollback (when using middleware)
• PANIC in libs/prisma-models/src/record.rs:161:30 | Invalid coercion encountered: ConversionFailure("Bytes
• Unique constraint error inside a transaction throws unparsed error (but works fine when using Node API)
• No PrismaClientKnownRequestError if error in transaction
• No PrismaClientKnownRequestError when unique constraint fails in transaction
• "Mongo is not yet supported" in databaseTypeToConnectorType()
• Nested update with updateMany does not update the updatedAt timestamps for related records properly
• Enable Type Discovery

Prisma Migrate

• Failure creating a migration with MSSQL: Introducing FOREIGN KEY constraint '...' on table '...' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
• Migration checksum EOL-independent
• need to run db push twice in order to apply changes
• Modifying enum value in Postgres causes an error
• Investigate and remove usage of --forceExit
• Removing element from enum not working
• Error: Error in migration engine. Reason: [migration-engine/connectors/sql-migration-connector/src/sql_renderer/mssql_renderer.rs:394:9] not yet implemented: DROP TYPE [dbo].[syspolicy_target_filters_type]
• Re-Introspection: introspect --url outputs additional lines which make output result unusable
• Check validity of having Unique Constraint and Primary Key Constraint on the same Column on SqlServer
• config.datasources[0].provider from GetConfig needs to be a string and not a string[]
• SQL Server: Unable to rename a column referenced by a relation
• Remove skipped SQL Server tests
• error: Error validating model "foo": The custom name bar specified for the @@unique attribute is already used as a name for a field. Please choose a different name.

Credits

Huge thanks to @benkenawell for helping!

📺 Join us for another "What's new in Prisma" livestream

Learn about the latest release and other news from the Prisma community by joining us for another "What's new in Prisma" livestream.

The stream takes place on Youtube on Thursday, March 04 at 5pm Berlin | 8am San Francisco.