Check for nested sql query after 'IN' keyword in the Prisma raw query.

Problem

Docs about raw-database-access also guide to use of nested SQL query when using IN keyword, but in the other raw queries use js variables literally. So, many developers have been confused about when to use nested SQL or just js variables if they don’t read the docs carefully. To use myself as an example, I didn’t follow the docs and use them without nested queries and Prisma raw SQL not working in my project without errors, so I had to spend a lot of time fixing them. Obviously, It was my mistake. However, It is not easy to find what is an error in that case because there is no type checking and no error!

Suggested solution

I would like to throw an error with the following message in the following case.

const ids = [1, 3, 5, 10, 20]
const result =
  await prisma.$queryRaw`SELECT * FROM User WHERE id IN (${ids})`

"Expected a value after 'IN' keyword should be the nested sql queries"

Alternatives

Additional context

Prisma uses sql-template-tag package for raw queries. Thus, to fix this issue, after adding this feature to sql-template-tag, Prisma should use the next updated sql-template-tag package. So, I asked about this feature to @blakeembrey, and he tell me his concerns about performance for adding this or additional checks. However, he also says additional checks may have to be executed under a development environment would be fine.

https://github.com/blakeembrey/sql-template-tag/pull/32

Actually, having each logic depending on whether it is a development environment or production environment is the way many projects do.

Thus, checking this condition would be very helpful for debugging and finding errors easily for many developers using Prisma raw queries!

[HwangTaehyun]

@SevInf Oh, thank you for reviewing. I think there is no problem regardless of different dialects when using Sql instance of sql-template-tag after ‘IN’ keyword. Using only js variables after ‘IN’ keyword should be avoided for different dialects if anything. In the PR discussion, Postgres is okay for only a js array variable but MySQL is not. I’m going to think about that point.

[SevInf]

Hi @HwangTaehyun! We understand that such warning would be a good improvement, however, I have to agree with sql-template-tag maintainers on implementation: simple substring match, similar to what you did in your PR likely will misfire in some cases, (part of them mentioned in PR discussion). Properly parsing SQL without stumbling over specifics of different dialects is would be quite a difficult task and require constant maintenance, which is just not worth it for this feature. We’d be fine with keeping this request open, but at the moment I am not sure how can we approach it without implementing fullu-featured SQL parser.