Prisma query
Hi Guys I am building a full-stack application using turbo-repo. Soo my backend is using serverless AWS and I have a shared database folder which I import from. When using the query system I had to set an env variable: PRISMA_QUERY_ENGINE_LIBRARY to tell pull the generated stuff from the right place. This has caused a lot of issues around the lambda sizes being massive! Soo I found the new way of using the query_compiler_bg.wasm. But I have the same issue where it is not pointing to the right generated folder as it in in a separate folder.
soo where it is trying to find it from here:
/Users/work/repos/project/services/employer/src/generated/prisma/query_compiler_bg.wasm
it is actually meant to find it from here:
/Users/work/repos/project/services/employer/node_modules/@relay/database/src/generated/prisma/query_compiler_bg.wasm.
I got this working for the library query engine because I just set the path:
/var/task/node_modules/@relay/database/src/generated/prisma/libquery_engine-rhel-openssl-1.0.x.so.node
7 Replies
You chose to debug with a human. They'll tinker with your query soon. If you get curious meanwhile, hop into
#ask-ai for a quick spin!You have a repo to share? 🤔
I Will create an example repo
it's a company repo i cannot really share it
Thanks 🙏
I figured out the problem and I think Iknow what the solution is. We have a turbo repo:
root
-- services:
---- employer:
------ node_modules:
--------@root/database/src/generated/prisma/query_compiler_bg.wasn
-- packages
---- Database:
------ client and all the other good stuff such as schema and etc
The schema is as shows:
generator client {
provider = "prisma-client-js"
output = "../generated/prisma"
engineType = "client"
}
it fails because when the backend service tries to get this client and generated types from the dependcy which is located in the turborepo packages/databases. It tries to find the query_compiler_bg.wasm in the wrong location:
/Users/work/repos/project/services/employer/node_modules/@relay/database/src/generated/prisma/query_compiler_bg.wasm.
whereas it should be:
/var/task/node_modules/@relay/database/src/generated/prisma/libquery_engine-rhel-openssl-1.0.x.so.node
is there a way we can override the path the same way we can with the library query engine:
PRISMA_QUERY_ENGINE_LIBRARY
Try this generator instead
Use ./generated/client to import the prisma client
@JeyJeyCodes
This generator I get issues with enum.js
Out of what is generated
But I will try agan
@Aman This generator is causing issues, because we are using serverless AWS and I don't know if that is causing issues:
"errorType": "TypeError",
"errorMessage": "The "path" argument must be of type string or an instance of URL. Received undefined",
"code": "ERR_INVALID_ARG_TYPE",
"stack": [
"TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string or an instance of URL. Received undefined",
" at __node_internal_captureLargerStackTrace (node:internal/errors:496:5)",
" at new NodeError (node:internal/errors:405:5)",
" at fileURLToPath (node:internal/url:1477:11)",
" at Object.<anonymous> (/packages/database/src/generated/prisma/client.ts:15:40)",
" at Module._compile (node:internal/modules/cjs/loader:1364:14)",
" at Module._extensions..js (node:internal/modules/cjs/loader:1422:10)",
" at Module.load (node:internal/modules/cjs/loader:1203:32)",
" at Module._load (node:internal/modules/cjs/loader:1019:12)",
" at Module.require (node:internal/modules/cjs/loader:1231:19)",
" at require (node:internal/modules/helpers:177:18)",
" at _tryRequireFile (file:///var/runtime/index.mjs:1092:37)",
" at _tryRequire (file:///var/runtime/index.mjs:1151:25)",
" at _loadUserApp (file:///var/runtime/index.mjs:1186:22)",
" at UserFunction.js.module.exports.load (file:///var/runtime/index.mjs:1235:27)",
" at start (file:///var/runtime/index.mjs:1454:42)",
" at file:///var/runtime/index.mjs:1464:7",
" at ModuleJob.run (node:internal/modules/esm/module_job:195:25)",
" at async ModuleLoader.import (node:internal/modules/esm/loader:337:24)",
" at async loadESM (node:internal/process/esm_loader:34:7)",
" at async handleMainPromise (node:internal/modules/run_main:106:12)"
@Aman Thank you, your suggestion inspired the fix I have been working on for 5 CRAZY DAYS