Skip to content

2.29.0
Compare
Choose a tag to compare
@millsp millsp released this 10 Aug 14:47
· 3819 commits to main since this release
2.29.0
866cf2d
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

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

Prisma Migrate

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.

Contributors

benkenawell
Assets 2
1 Join discussion