fix(driver-adapters): support Transaction Isolation Levels in PlanetScale

[jkomyno]

This PR:

• Closes [DA] Planetscale engine tests: interactive_tx #4469
• Closes https://github.com/prisma/team-orm/issues/953

Explanation

We originally thought that Transaction Isolation Levels for PlanetScale worked fine in TypeScript-land, and only failed in Rust tests with the error message:

Transaction characteristics can't be changed while a transaction is in progress (errno 1568) (sqlstate 25001) during query: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

As it turns out, that wasn't the case: there were actual issues in the way we were executing SET TRANSACTION ISOLATION LEVEL ... queries.

Consider the following snippet, constructing a planetScale.Client instance:

import * as planetScale from '@planetscale/database'

async function main() {
  const databaseURL = 'mysql://root:root@localhost:33807/PRISMA_DB_NAME'
  const url = new URL('http://root:root@127.0.0.1:8085')
  url.pathname = new URL(databaseURL).pathname
  
  const client = new planetScale.Client({ url: url.toString() })

  ... // TODO
}

Before this PR, using transactions with custom isolation levels in @prisma/adapter-planetscale was virtually equivalent to:

  {
    await client.transaction(async (tx) => {
      // 1. Custom isolation level
      await client.execute('SET TRANSACTION ISOLATION LEVEL SERIALIZABLE')

      // 2. any query within the transactional context `tx`
      const query = await tx.execute('SELECT 1') 
      console.log('[query]')
      console.dir(query, { depth: null })
    })
  }

This results in a runtime error. As written in the MySQL docs,

You can set transaction characteristics globally, for the current session, or for the next transaction only.

So, this PR changes the driver-adapters part of Query Engine to trigger the following JS logic instead:

  {
    // 1. Custom isolation level
    await client.execute('SET TRANSACTION ISOLATION LEVEL SERIALIZABLE')

    await client.transaction(async (tx) => {
      // 2. any query within the transactional context `tx`
      const query = await tx.execute('SELECT 1')
      console.log('[query]')
      console.dir(query, { depth: null })
    })
  }

[CLAassistant]

All committers have signed the CLA.

[github-actions]

WASM Query Engine file Size

Engine	This PR	Base branch	Diff
Postgres	2.057MiB	2.057MiB	4.000B
Postgres (gzip)	820.543KiB	820.453KiB	93.000B
Mysql	2.027MiB	2.027MiB	-7.000B
Mysql (gzip)	808.051KiB	808.035KiB	17.000B
Sqlite	1.919MiB	1.919MiB	4.000B
Sqlite (gzip)	766.193KiB	766.277KiB	-86.000B

[codspeed-hq]

CodSpeed Performance Report

Merging #4966 will not alter performance

_{Comparing fix/planetscale-transactions (35ba9f4) with main (a6977e5)}

Summary

✅ 11 untouched benchmarks

[SevInf]

I am really not sure about that.
client.execute is not guaranteed to be executed on the same connection transaction will later start and it only works it tests because there are no concurrent requests.

And since we are not making a change on the adapter level, but on the driver itself - it is definietely not guaranteed that for any potential mysql adapter executeRaw and startTransaction are executed on the same connection.

I think the way we should do it instead is:

• change startTransaction in driver interface to accept isolation level. This is how I originally implemented it, and then we changed it for logging' sake and I think this was a mistake.
• now driver is responsible for both starting the transaction and setting isolation level.
• in planetscale driver, we can now first secure the connection (IIRC, they have a session api for that), set isolation level and only then start the transaction.

[jkomyno]

client.execute is not guaranteed to be executed on the same connection transaction will later start and it only works it tests because there are no concurrent requests.

You raised a good point, but I think we can use the Connection API, without refactoring as much as you suggest:

  {
    const conn = await client.connection()
    await conn.execute('SET TRANSACTION ISOLATION LEVEL SERIALIZABLE')
    await conn.transaction(async (tx) => {
      // ...
    })
  }

What do you think?

[jkomyno]

client.execute is not guaranteed to be executed on the same connection transaction will later start and it only works it tests because there are no concurrent requests.

You raised a good point, but I think we can use the Connection API, without refactoring as much as you suggest:

  {
    const conn = await client.connection()
    await conn.execute('SET TRANSACTION ISOLATION LEVEL SERIALIZABLE')
    await conn.transaction(async (tx) => {
      // ...
    })
  }

What do you think?

From what I can see, implementing this means:

• keeping this engines PR as it is
• adjusting the @prisma/adapter-planetscale in TypeScript

[SevInf]

Sorry, I don't quite see how that would work without refactor I am suggesting, can you clarify a bit?
We need to know what isolation level is in the startTransaction in order to do so. Which means that we need to change startTransaction signature the way I suggesting and stop issuing SET TRANSACTION ISOLATION LEVEL statements on the engine side. What am I missing?

[jkomyno]

Deprecated by #4967 and prisma/prisma#24878.