Jonathan Marbutt
02/09/2022, 9:06 PMDateTime? @db.Timestamp(6)
Jonathan Marbutt
02/09/2022, 9:06 PMJonathan Marbutt
02/09/2022, 9:06 PMnew Date()
in the code but I would like to do a default, when I try to use @db.default(now())
it doesn’t workgenedy
02/09/2022, 9:45 PMgenedy
02/09/2022, 9:46 PMDan M
02/09/2022, 11:47 PMconst usage = await prisma.nation.findUnique({
select: {
_count: {
select: {
locales: true,
transitsOriginatingFromThisNation: true,
transitsDestinedForThisNation: true,
conflicts: { where: { isUserEntered: true } },
},
},
},
where: { id },
});
Dan M
02/09/2022, 11:48 PMwhere
clause on conflicts
How do you do a where clause within aggregate count?Tyler Clendenin
02/10/2022, 12:49 AMMichael Aubry
02/10/2022, 1:35 AMBrothak
02/10/2022, 8:23 AM[*] Changed the `addresses` table
[-] Removed foreign key on columns (entity_id)
[+] Added foreign key on columns (entity_id)
[*] Changed the `entity_metadata` table
[-] Removed foreign key on columns (tag_id)
[+] Added foreign key on columns (tag_id)
Brothak
02/10/2022, 8:24 AMJonas
02/10/2022, 8:25 AMprisma migrate
?user
02/10/2022, 9:47 AMNathaniel Babalola
02/10/2022, 10:18 AMNathaniel Babalola
02/10/2022, 10:19 AMFlorian
02/10/2022, 10:23 AMmodel Something {
id String @id @default(dbgenerated("nanoid(\'SMTH_\')"))
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
....other fields....
}
(All of them have that default dbgenerated thing for the id
column)
Whenever I try to do a migration using prisma migrate dev
the tool keeps trying to add the following SQL to the migration for all the tables:
ALTER TABLE "something" ALTER COLUMN "id" SET DEFAULT nanoid('SMTH_');
Even though it has been correctly set on the initial migration:
CREATE TABLE "something" (
"id" TEXT NOT NULL DEFAULT nanoid('SMTH_'),
"createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
"updatedAt" TIMESTAMP(3) NOT NULL,
CONSTRAINT "something_pkey" PRIMARY KEY ("id")
);
I keep removing them by hand, but is it possible for it not to create that everytime? 😄
Btw, I'm using prisma@3.9.1
with postgres:10.13
, I can't tell if it happened on previous versions, I did my setup this week 😄Mishase
02/10/2022, 10:36 AM// prisma:query SELECT "public"."Session"."token", "public"."Session"."userId" FROM "public"."Session" WHERE "public"."Session"."token" = $1 OFFSET $2
// prisma:query SELECT "public"."User"."id" FROM "public"."User" WHERE "public"."User"."id" IN ($1) OFFSET $2
await prisma.session.findUnique({
select: {
user: { select: { id: true } },
},
where: {
token,
},
});
// prisma:query SELECT "public"."User"."id" FROM "public"."User" WHERE "public"."User"."id" IN ($1) OFFSET $2
// prisma:query SELECT "public"."Session"."token", "public"."Session"."userId", "public"."Session"."createdAt" FROM "public"."Session" WHERE "public"."Session"."token" = $1 OFFSET $2
await prisma.session.findUnique({
include: {
user: { select: { id: true } },
},
where: {
token,
},
});
// prisma:query SELECT "User".id FROM "User" WHERE "User".id = (SELECT "Session".userId FROM "Session" WHERE "Session".token = $1)
await prisma.$queryRaw`SELECT "User".id FROM "User" WHERE "User".id = (SELECT "Session"."userId" FROM "Session" WHERE "Session".token = ${token})`;
// prisma:query SELECT "User".id FROM "User" LEFT JOIN "Session" ON "User".id = "Session"."userId" WHERE "Session".token = $1
await prisma.$queryRaw`SELECT "User".id FROM "User" LEFT JOIN "Session" ON "User".id = "Session"."userId" WHERE "Session".token = ${token}`;
Josef Henryson
02/10/2022, 1:23 PMMatheus Assis
02/10/2022, 1:24 PMcreateMany
doesn't allow us to create the relations. What I'm doing is to first call createMany
for the "base" write, and then I get the recently created ids with findMany
and then call createMany
again for each of the relations. The problem with this is that if some of the relations fail, the previous writes still exists. So I need to manually delete them in this case, and even this is not perfect, because while one of the elements on the createMany may have failed, not all of them would.
I was planning on using a transaction but I saw that it doesn't help me in this case. What would be the best practice to do this then? Manually loop through each record and use nested write instead, and not do batches with createMany? But then it'd take a looong time instead. Is there a different solution?Jonathan Marbutt
02/10/2022, 3:21 PMTimed out fetching a new connection from the connection pool. More info: <http://pris.ly/d/connection-pool> (Current connection pool timeout: 10, connection limit: 3)
on a project that has the connection string with the connection pool to 100. And we are verifying that when the app starts up.
It is a nestjs app running on Azure connecting to an AWS Aurora database. We have another project that is almost identical that is not having this issue. They share the same prisma client library. We are trying to get this to production ready but have no idea why this continues to happenVR
02/10/2022, 6:44 PMAlonso A.
02/10/2022, 7:50 PMLogan
02/10/2022, 8:39 PMMo El
02/11/2022, 12:31 AMΓιώργος Κραχτόπουλος
02/11/2022, 5:35 AMobjectType
level at nexus?user
02/11/2022, 8:31 AMMichael Aubry
02/11/2022, 4:30 PMMichael Aubry
02/11/2022, 5:13 PMJessica Otte
02/11/2022, 6:35 PMeffectiveDate DateTime? @map("effective_date") @db.Date
• Query looks like
const courses: Course[] = await prisma.$queryRaw<Course[]>`
SELECT
id,
course_number,
effective_date as "effectiveDate",
....
But if I try and do effectiveDate.getDate() or something, I get a runtime error; and if I console.log typeof effectiveDate
, it tells me that it's a string. If I do my query using prisma.findMany
, it works fine.
I do see in the docs it says
Type caveats when using raw SQL: When you type the results of $queryRaw, the raw data does not always match the suggested TypeScript type.So, is it expected behavior that the date returns as a string, or am I doing something wrong? And if it matters,
prisma --version
gives me
prisma : 3.0.1
@prisma/client : 3.7.0
Current platform : windows
Jorge
02/11/2022, 7:02 PMprisma migrate deploy
programmatically ?