`START TRANSACTION`, "Error 1295: This command is not supported in the prepared statement protocol yet"

Bug description

Invalid `prisma.executeRaw()` invocation:

Raw query failed. Code: `1295`. Message: `This command is not supported in the prepared statement protocol yet`

How to reproduce

1. Create a schema.
2. Generate the client
3. Run prisma.executeRaw("START TRANSACTION")
4. See error

Expected behavior

To start a transaction

Prisma information

Schema:

datasource mysql {
  provider = "mysql"
  url      = env("DATABASE_URL")
}

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

Environment & setup

• OS: Ubuntu 20.04
• Database: MariaDB v10.2
• Node.js version: 14.2.0
• Prisma version:

@prisma/cli          : 2.3.0
Current platform     : debian-openssl-1.1.x
Query Engine         : query-engine e11114fa1ea826f9e7b4fa1ced34e78892fe8e0e (at node_modules/@prisma/cli/query-engine-debian-openssl-1.1.x)
Migration Engine     : migration-engine-cli e11114fa1ea826f9e7b4fa1ced34e78892fe8e0e (at node_modules/@prisma/cli/migration-engine-debian-openssl-1.1.x)
Introspection Engine : introspection-core e11114fa1ea826f9e7b4fa1ced34e78892fe8e0e (at node_modules/@prisma/cli/introspection-engine-debian-openssl-1.1.x)
Format Binary        : prisma-fmt e11114fa1ea826f9e7b4fa1ced34e78892fe8e0e (at node_modules/@prisma/cli/prisma-fmt-debian-openssl-1.1.x)
Preview Features     : transactionApi

[JuanM04]

Maybe, you could add a function that works with the text protocol. Something like prisma.dangerouslyExecuteRaw().

[pimeys]

Hey, so bit of an explanation and background what is going on here…

Typically databases offer two protocols: the text and the binary protocol. Text protocol allows one to send queries, such as SELECT 1 or DROP TABLE "Users", and the data is sent as text (as the name implies). The binary protocol is more interesting here, because it allows us to prepare queries, such as SELECT ?, store the queries to the server and execute them with different parameters. It saves lots of time when repeating similar queries, but more importantly it allows us to pass the parameters as they are to the database, which then escapes them and prevents any SQL injection attacks from happening.

Basically what queryRaw and executeRaw do is they both take the parameters out from the query, replacing them with placeholders; therefore protecting from injections. But, this then leads to an interesting problem:

Some of the queries cannot be executed using the binary protocol!

So good examples would be BEGIN, COMMIT and ROLLBACK, that in most databases expect one to use the text protocol, meaning we get to see errors like this when using the executeRaw or queryRaw APIs.

What we could think about is, for example, implementing a new command executeBatch. As the name implies, it would be meant for batch executions, which again are usually only allowed using the text protocol (except in the Microsoft SQL Server, which allows preparing multiple queries at once).

So we could do something like:

client.executeBatch(
    "BEGIN; INSERT INTO `cats` (name, age) VALUES ('Musti', 7); COMMIT;"
);

Now, this being a text protocol, one big problem with it is we cannot parameterize any of the user-provided values. An API that puts the user and the safety of the system at risk by forcing to check every parameter for escaping is not really the best API. It is possible, but I’m not that convinced of its usefulness.