2.29.0

[Jolg42]

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 to address one of our most popular feature requests.

Interactive Transactions give you more control over how queries are executed within a transaction. One common use case is when the result of one query depends on another query, and you want to run both queries within a single transaction.

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"]
}

For example, here's an interactive transaction that is used to create a cinema booking if there's availability and create a notification:

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

const email = 'anna@prisma.io'
const imdbId = '9606374'

const [booking, notifications] = await prisma.$transaction(async (prisma) => {
  const screening = await prisma.screening.findUnique({
    where: {
      imdbId,
    },
    include: {
      _count: {
        select: { bookings: true },
      },
    },
  })

  if (screening === null) {
    throw new Error('screening not found')
  }

  if (
    screening._count &&
    screening._count.bookings >= screening.ticketLimit
  ) {
    throw new Error('Screening booked out')
  }

  // Create the booking
  const booking = await prisma.booking.create({
    data: {
      screening: {
        connect: {
          id: screening.id,
        },
      },
      user: {
        connect: {
          email,
        },
      },
    },
    include: {
      screening: {
        select: {
          movieName: true,
          imdbId: true,
        },
      },
    },
  })

  const notification = await prisma.notification.create({
    data: {
      message: `Your booking for ${booking.screening.movieName} is confirmed. Booking id: ${booking.id}}`,
      user: {
        connect: {
          email: email,
        },
      },
    },
  })

  return [booking, notification]
})

You can find the associated schema and working example here.

Learn more about Interactive Transactions in our documentation. We would love to know your feedback! If you have any comments or run into any problems, you can use this issue.

Named Constraints is 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.

---

This discussion was created from the release 2.29.0.

[scriptcoded]

Glad to see that we've at least got the option to use interactive transactions, and even happier that you're going "more semver". I've had a few scares with Prisma updating with breaking changes in the past! 🙈

[ludralph]

Hi there,

To keep our discussions organized and focused on the most relevant topics, we’re reviewing and tidying up our backlog. As part of this process, we’re closing discussions that haven’t had any recent activity and appear to be outdated.

If this discussion is still important to you or unresolved, we’d love to hear from you! Feel free to reopen it or start a new one with updated details.

For more details about our priorities and vision for the future of Prisma ORM, check out our latest blog post: https://www.prisma.io/blog/prisma-orm-manifesto.

Thank you for your understanding and being part of the community!