LRT: Interactive Transactions Epic

[matthewmueller]

Problem

Long-running transactions are a very commonly used functionality of database that has influenced how a lot of developers think and build their applications.

While there are alternative ways to conceive a feature without them, leading to more scalable code, these ways aren't obvious and can complicate the code of applications that wouldn't suffer from long-running transaction shortcomings.

Moreover, users can't bear the cost of porting pre-existing application heavily relying on long-running transactions to a new paradigm.

Solution

Our new transaction API will allow you to add arbitrary logic within a transaction. This gives users a simple mental model for working with transactions and reduces the burden of porting existing applications to Prisma.

Code Example

import { PrismaClient } from '@prisma/client'

async function main() {
  const prisma = new PrismaClient()

  const posts = await prisma.$transaction(async (tx) => {
    // we can do our usual queries/await them
    const user = await tx.user.findUnique({
      where: {
        email: 'john@doe.io'
      }
    })

    if (!user) {
      // we can also throw errors of our own
      throw new Error('User does not exist')
    }

    // we can process long running operations
    const copiedPost1 = await fetchData(1)

    // data can be persisted after "long" ops
    const post1 = await tx.post.create({
      data: {
        title: copiedPost1['title'],
        content: copiedPost1['content'],
        author: {
          connect: {
              email: 'john@doe.io'
          }
        }
      }
    })

    // unhandled exceptions trigger rollback
    const post2 = await tx.post.create({
      data: {
        title: undefined as any as string,
        content: undefined as any as string,
        author: {
          connect: {
              email: 'wrong@email.io'
          }
        }
      }
    })

    // we can return any custom return value
    return [post1, post2]
  })
}

// PS: we agree that this is a bad practice
function fetchData(id: string | number) {
  return fetch(`https://myservice.co/api/${id}`)
  .then(response => response.json()) as
  Promise<{title: string, content: string}>
}

Tasks

• LRT: Break down the design into discrete tasks #7957 @dpetrick @millsp

TypeScript Client

• LRT: Put up a simple mock server for prototyping #8000 @millsp
• LRT: Integrate BinaryEngine transaction calls #8090
• LRT: Integrate LibraryEngine transaction calls #8091
• LRT: Implement transaction scheduler #8087
• LRT: Implement opt-in preview feature guards #8088
• LRT: Implement $transaction(async (prisma) => {...}) #8092
• LRT: Implement timeout configuration options #8093
• LRT: Disallow nested transactions #8094
• LRT: Proxy the prisma client within a transaction #8095
• LRT: Generate types for prisma callback #8096
• LRT: Integrate with middlewares #8097
• LRT: Integrate error handling for engines responses #8098
• LRT: Integrate auto actions #8099
• LRT: Integrate scheduler, callback, and auto actions #8100
• LRT: Remove mocks and write test suite #8101
• LRT: Review concurrency design #8277

Query Engine

• LRT: Set up Query Engine REST endpoint. #8016
• LRT: Set up Query Engine Node-API function. #8017
• LRT: Design Query Engine transaction cache #8018
• LRT: Redo Query Engine executor interface #8019

Note: The following issues might be easy to fix while implementing LRT, but not necessary for completing the epic.

• No PrismaClientKnownRequestError when unique constraint fails in transaction #7786
• No PrismaClientKnownRequestError if error in transaction #7399

References

• Community issue: API for interactive transactions with dependencies between write-operations #1844
• Internal Document