Misan
06/23/2022, 10:54 AMnpx prisma migrate deploy
on that machine when updating the piece of software? What can I do to avoid conflicts?Michael Gates
06/23/2022, 12:18 PMprisma migrate
, it always defaults to using NPM instead of Yarn, which causes node_modules
to be created and the prisma client to be generated in there, rather than the path I gave it in the schema.prisma
client output.user
06/23/2022, 12:49 PMuser
06/23/2022, 12:49 PMuser
06/23/2022, 12:49 PMGhimsim Chua
06/23/2022, 4:09 PMuser
06/23/2022, 4:56 PMuser
06/23/2022, 4:56 PMuser
06/23/2022, 4:58 PMuser
06/23/2022, 5:33 PMJC
06/23/2022, 6:34 PMMatias
06/23/2022, 8:03 PMJoe McKenney
06/23/2022, 8:42 PMpackage.json
file which seems to breaks various assumptions of package managers (e.g. https://github.com/prisma/prisma/issues/13893, https://github.com/yarnpkg/berry/issues/4572). The latter is an issue I just filed on yarn but it is worth highlighting how it relates to the prisma change.
For us, we have a polyglot monorepo that utilizes yarn workspaces. We also have 3 databases, all of which we configure and access with Prisma. Accordingly, we generate multiple prisma clients in one monorepo (with more to come as we add additional services/apps). We utilize the client generation output configuration to plop the generated client into the ./dist
of appropriately named and located package e.g. @{company-name}/users-service-orm
(effectively wrapping it in our own package and tracking it as part of our package dependency graph).
As a rule, all of our package build artifacts (./dist
dirs for TS packages in our monorepo) are gitignored in our top-level .gitignore
as well as package-specific `.gitignore`s. We agree with y'all that build artifacts shouldn't end up in version control. The package.json
that ends up in client package's ./dist
dir are getting picked up by yarn workspaces 😞 e.g. yarn workspace globbing doesn't respect gitignored files/dirs.
That is very much a yarn problem but it does feel like the change to produce package.json
files as part of client generation relies heavily on the assumption that you will put the generated SDK into node modules. I've read your docs on this matter and understand the reasoning but would also argue that it is not necessarily the most natural solution in all cases (e.g. a large polyglot monorepo).
One idea/proposal - would you consider configuration for the client generation that would allow us to avoid creating a package.json, equivalent to saying that we will manage these build artifacts ourselves? Open to other ideas as well.ut dev
06/23/2022, 10:08 PMmodel Snippet {
id String @id @default(uuid())
title String
user _User_ @relation(fields: [_userId_], references: [_id_])
userId String
technology _Technology_ @relation(fields: [_technologyId_], references: [_id_])
technologyId String
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
tags _Tag_[]
Visibility _Visibility_? @relation(fields: [_visibilityId_], references: [_id_])
visibilityId String?
}
model Tag {
id String @id @default(uuid())
name String
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
Snippet _Snippet_? @relation(fields: [_snippetId_], references: [_id_])
snippetId String?
}
Running
pnpm prisma migrate dev
To update my schema does not add the tags field to my snippet model, what am I missing?
Am I creating wrong relation using that syntax, basically a Snippet should be able to contain multiple Tags.user
06/24/2022, 10:51 AMuser
06/24/2022, 10:51 AMuser
06/24/2022, 10:51 AMNigel Greenway
06/24/2022, 11:13 AMuser
06/24/2022, 12:06 PMuser
06/24/2022, 12:06 PMut dev
06/24/2022, 8:52 PMmodel Snippet {
id String @id @default(uuid())
title String
user _User_ @relation(fields: [_userId_], references: [_id_])
userId String
technology _Technology_ @relation(fields: [_technologyId_], references: [_id_])
technologyId String
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
Visibility _Visibility_? @relation(fields: [_visibilityId_], references: [_id_])
visibilityId String?
Tag _Tag_[]
}
model Tag {
id String @id @default(uuid())
name String
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
Snippet _Snippet_? @relation(fields: [_snippetId_], references: [_id_])
snippetId String?
}
Running the migration afterwards like pnpm prisma migrate dev
Gives me following error:
Error: P3006
Migration 20220623223220_update_relation_for_snippet_and_tags
failed to apply cleanly to the shadow database.
Error:
db error: ERROR: foreign key constraint "Snippet_tagId_fkey" cannot be implemented
DETAIL: Key columns "tagId" and "id" are of incompatible types: text[] and text.
0: sql_migration_connector::validate_migrations
at migration-engine/connectors/sql-migration-connector/src/lib.rs:272
1: migration_core::state::DevDiagnostic
at migration-engine/core/src/state.rs:250
Nigel Greenway
06/24/2022, 9:59 PMprisma generate
call?Kay Khan
06/25/2022, 3:51 PMmodel users {
id String @id @default(dbgenerated("gen_random_uuid()")) @db.Uuid
email String
password String?
created_at DateTime @default(now())
updated_at DateTime @updatedAt
deleted_at DateTime?
}
if i create a new user, updated_at is not autofilled
generated sql
CREATE TABLE "users" (
"id" UUID NOT NULL DEFAULT gen_random_uuid(),
"email" TEXT NOT NULL,
"password" TEXT,
"created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
"updated_at" TIMESTAMP(3) NOT NULL,
"deleted_at" TIMESTAMP(3),
CONSTRAINT "users_pkey" PRIMARY KEY ("id")
);
Michael Plaxico
06/25/2022, 5:50 PMfindUnique
and no records match my query, I get an internal server error. I can’t even prevent this from happening by specifying rejectOnNotFound: false
. It happens to matter what.
Invalid `prisma.product.delete()` invocation:
An operation failed because it depends on one or more records that were required but not found. Record to delete does not exist.
Error:
Invalid `prisma.product.delete()` invocation:
An operation failed because it depends on one or more records that were required but not found. Record to delete does not exist.
at RequestHandler.request (/Users/meh/codebase/blah/blah-api/node_modules/@prisma/client/runtime/index.js:49022:15)
at PrismaService._request (/Users/meh/codebase/blah/blah-api/node_modules/@prisma/client/runtime/index.js:49919:18)
at ProductsService.deleteProduct (/Users/meh/codebase/blah/blah-api/src/products/products.service.ts:27:12)
at ProductsResolver.deleteProduct (/Users/meh/codebase/blah/blah-api/src/products/products.resolver.ts:45:12)
at target (/Users/meh/codebase/blah/blah-api/node_modules/@nestjs/core/helpers/external-context-creator.js:77:28)
at /Users/meh/codebase/blah/blah-api/node_modules/@nestjs/core/helpers/external-proxy.js:9:24
joao.santos
06/25/2022, 7:54 PMdataini: { equals: "2006-01-23T19:00:00.000Z" }
if I do this it works but if I want only to specify a date like this 2006-01-23 it doesnt return nothing....akku
06/26/2022, 7:34 AMakku
06/26/2022, 7:34 AMakku
06/26/2022, 8:03 AMTakeo Kusama
06/26/2022, 10:01 AMprisma.some_table.create({ date_column: new Date(2021,9,1) })
may interpret 2021-08-31T150000.000Z as UTC to 2021-08-31T000000.000Z so, the result it saves 2021-08-31 as the date.
It is ideal if prisma orm accept date.toLocaleString() as date type record value, but it doesn’t. For codebase clean as possible, I don’t want to rely on add offset base solutions. Is there any idea?pyjama929
06/26/2022, 2:02 PMmodel Likes {
id String @id @default(cuid())
userId String
itemId String
liked Boolean
createdAt DateTime @default(now())
updatedAt DateTime @default(now())
user User @relation(fields: [userId], references: [id], onDelete: Cascade)
items Items @relation(fields: [itemId], references: [id], onDelete: Cascade)
}
model Items {
id String @id @default(cuid())
content String
userId String
done Boolean @default(false)
createdAt DateTime @default(now())
updatedAt DateTime @default(now())
completedAt DateTime?
user User @relation(fields: [userId], references: [id], onDelete: Cascade)
comments Comments[]
likes Likes[]
products Products[]
}
model User {
id String @id @default(cuid())
name String? @unique @default(cuid())
displayName String?
location String?
bio String?
twitter String?
email String? @unique
emailVerified DateTime?
image String?
lastOnline DateTime?
isAdmin Boolean @default(false)
isPremium Boolean @default(false)
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
accounts Account[]
sessions Session[]
items Items[]
comments Comments[]
likes Likes[]
products Products[]
}
The error I get
Invalid `prisma.likes.upsert()` invocation:
{
where: {
userId: 'cl3mvrzw00040qj9vsn914xn0'
~~~~~~
},
create: {
userId: 'cl3mvrzw00040qj9vsn914xn0',
itemId: 'cl472xhbd0200va9vtfanjkqv',
liked: true
},
update: {
liked: true
}
}
Unknown arg `userId` in where.userId for type LikesWhereUniqueInput. Did you mean `id`? Available args:
type LikesWhereUniqueInput {
id?: String
}