Closed frankcollins3 closed 1 year ago
took an hour break between 8:30pm - 9:30pm the routes worked with that message that there were 10 instances running
event - compiled client and server successfully in 1587 ms (349 modules)
wait - compiling /api/graphql (client and server)...
event - compiled successfully in 771 ms (82 modules)
wait - compiling...
event - compiled client and server successfully in 2.6s (368 modules)
👎 warn(prisma-client) There are already 10 instances of Prisma Client actively running.
[10:18pm]
env.local && NEXT_PUBLIC_ENV-VAL to allow .env.local part of this issue is wondering where to put a prisma configuration file and I think it might be graphql/prisma.ts [10:36pm]
pooling error. this is a file to be: exported by graphql/prisma.ts imported by graphql/resolvers.ts to essentially be (not sure if that's middleware?) but logic between prisma running.
[10:50pm]
continually modifying code with chatGPT to be honest Type '{ url: string | undefined; maxConcurrentQueries: number; }' is not assignable to type 'Datasource'. Object literal may only specify known properties, and 'maxConcurrentQueries' does not exist in type 'Datasource'.ts(2322) (property) maxConcurrentQueries: number No quick fixes available [10:57pm]
import { PrismaClient } from '@prisma/client';
const prisma = new PrismaClient();
prisma.$connect();
prisma.$on('beforeExit', () => {
prisma.$disconnect();
});
prisma.$use(async (params, next) => {
if (params.action === 'query') {
params.engine?.forceTransaction = true;
params.engine?.maxConcurrentQueries = 100; // Set the desired value
}
return next(params);
});
export default prisma;
This comparison appears to be unintentional because the types 'PrismaAction' and '"query"' have no overlap.ts(2367) (parameter) params: Prisma.MiddlewareParams No quick fixes available
[10:58pm]
import { PrismaClient } from '@prisma/client';
const prisma = new PrismaClient({
datasources: {
db: {
url: process.env.NEXT_PUBLIC_DATABASE_URL,
},
},
maxConcurrentQueries: 100, // Set the desired value
});
prisma.$connect()
.then(() => {
// Prisma Client is now connected
})
.catch((error) => {
console.error('Failed to connect to the database:', error);
process.exit(1);
});
export default prisma;
Type 'number' is not assignable to type 'never'.ts(2322) (property) maxConcurrentQueries: never No quick fixes available
[11:02pm]
looking into examples outside of chatGPT; went to prisma docs & see this: datasource db { provider = "postgresql" url = "postgresql://johndoe:mypassword@localhost:5432/mydb?connection_limit=5&pool_timeout=2" } [11:07pm]
from the docs sent to chatGPT: looking into examples outside of chatGPT; went to prisma docs & see this: datasource db { provider = "postgresql" url = "postgresql://johndoe:mypassword@localhost:5432/mydb?connection_limit=5&pool_timeout=2" }
chatGPT response:
I apologize for any confusion caused. The connection string parameter connection_limit in the PostgreSQL connection string is not directly related to Prisma's maxConcurrentQueries functionality. They serve different purposes:
connection_limit in the PostgreSQL connection string sets the maximum number of concurrent connections allowed by the PostgreSQL server. It limits the total number of connections that can be established to the database.
maxConcurrentQueries in Prisma's configuration sets the maximum number of concurrent queries that the Prisma Client can make to the database. It limits the number of queries that can be executed simultaneously by the Prisma Client.
The connection_limit parameter in the PostgreSQL connection string controls the number of connections to the database server, while maxConcurrentQueries in Prisma controls the number of queries made by the Prisma Client.
If you're using Prisma with TypeScript and encountering issues with the maxConcurrentQueries option, could you provide more details about the specific error or behavior you're experiencing? That would help me assist you more effectively in resolving the issue.
Once again, I apologize for any confusion caused, and I'm here to provide further assistance.
referring to prisma docs after chatGPT said the suggestion of connection string with connection_limit in string 👎 👎
foul ball on chatGPT part but it also saves much time so <3
// chatGPT had us completely trying to extend a type declaration with an interface to assert maxConcurrentConnections // steered away from the solution // actual google search: maxConcurrentQueries in prisma
prisma/schema.prisma
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
NEXT_PUBLIC_DATABASE_URL=postgresql://postgres:esppsi777@localhost:5432/waterapp
chat can you help me determine the appropriate connection_limit with this? you suggested a limit of 100 & the docs have the example set to 5 it seems 5 is too low because iterm2 already said "already 10 instances of prisma"
[11:47pm]
datasource db {
provider = "postgresql"
**url = env("NEXT_PUBLIC_DATABASE_URL")** // changed DATABASE_URL to NEXT_PUBLIC_DATABASE_URL
}
// oh wow while posting this I changed .env.local to include the connection_limit=50 string param.
NEXT_PUBLIC_DATABASE_URL=postgresql://postgres:esppsi777@localhost:5432/waterapp?connection_limit=50
editing .env.local might have to do with this below returned iterm message confirming no change during prisma migrate
Environment variables loaded from .env Prisma schema loaded from prisma/schema.prisma Datasource "db": PostgreSQL database "waterapp", schema "public" at "localhost:5432"
Already in sync, no schema change or pending migration was found.
✔ Generated Prisma Client (4.6.1 | library) to ./node_modules/@prisma/client in 5.84s
[11:56pm]
to me this error message kind of makes sense. There aren't any schema changes outside of conn_limit string param
Already in sync, no schema change or pending migration was found.
✔ Generated Prisma Client (4.6.1 | library) to ./node_modules/@prisma/client in 336ms
[12:01pm]
👍 routes. but we'll see. [12:05am]
attempting to do: build login. now the route that successfully returned users, so that usernames can be pushed to redux state ( to check for unique constraint during sign up process)
error: Working route returns connection pool issue
proposed approach: 0: restart server / take 20 minute walk lol. also, since I know the route is good: localStorage.setItem(users[]) so that the data is retrievable for testing.
1: no clue so asked AI.. chat mentioned connection pooling so diving into that.
anecdotal but: // have had this issue testing routes late at night after hitting DB all day and usually go for a walk to come back in an hour or so // DB is then working back to normal after a bit of a break.