PrismaNuts
11/30/2021, 10:30 PMJames Homer
12/01/2021, 12:30 AMGezim
12/01/2021, 5:43 AMInvalid prisma.account.upsert() invocation
at runtime. TypeScript doesn’t show any issues. Details are here: https://github.com/prisma/prisma/discussions/10524Gezim
12/01/2021, 5:43 AMGezim
12/01/2021, 5:43 AMuser
12/01/2021, 9:01 AMMradul Jain
12/01/2021, 9:37 AMMradul Jain
12/01/2021, 9:38 AMMradul Jain
12/01/2021, 9:38 AMDaniel Saldarriaga
12/01/2021, 9:57 AMuser
12/01/2021, 2:00 PMLars Ivar Igesund
12/01/2021, 2:10 PMEmre Deger
12/01/2021, 2:58 PMid: 1n
) and JSON response (id: 1
) data do not match. Anyone have an idea?Josh
12/01/2021, 3:21 PMrdunk
12/01/2021, 4:29 PMrdunk
12/01/2021, 4:34 PMChris Bitoy
12/01/2021, 5:48 PMmodel Post {
id Int @id @default(autoincrement())
title String
tags PostTags[]
}
model PostTags {
id Int @default(autoincrement())
post Post? @relation(fields: [postId], references: [id])
tag Tag? @relation(fields: [tagId], references: [id])
postId Int?
tagId Int?
@@id([postId, tagId])
}
model Tag {
id Int @id @default(autoincrement())
name String @unique
posts PostTags[]
}
//Error
Error parsing attribute "@default": The `autoincrement()` default value is used on a non-indexed field even though the datasource does not support this.
joao.santos
12/01/2021, 6:33 PMconst user = await prisma.users.findFirst({
include: {
companies: true,
},
})
I get the relation table in "companies" instead of the companie table...
user {
id: 1,
createdAt: 2021-12-01T13:33:47.009Z,
updatedAt: 2021-12-01T13:33:47.010Z,
email: '<mailto:user1@users.com|user1@users.com>',
name: 'User 1',
lastSeen: null,
companies: [ { companieId: 1, userId: 1 } ]
}
SCHEMA:
model Users {
id Int @id @default(autoincrement()) //@default(uuid())
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
email String @unique
name String @db.VarChar(255)
lastSeen DateTime? @updatedAt
//RELATIONS
companies Companies_Users[]
}
model Companies {
id Int @id @default(autoincrement()) //@default(uuid())
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
name String @db.VarChar(255)
email String @unique
//RELATIONS
users Companies_Users[]
}
model Companies_Users {
companieId Int
companie Companies @relation(fields: [companieId], references: [id], onDelete: Cascade, onUpdate: Cascade)
userId Int
user Users @relation(fields: [userId], references: [id], onDelete: Cascade, onUpdate: Cascade)
@@id([companieId, userId])
@@map("_Companies_Users")
}
Can someone point what Im doing wrong pls?user
12/01/2021, 9:25 PMVibhuti Gupta
12/01/2021, 9:40 PMquery{
getUserData(username:"^(hung|dhu)($|[0-9]+$|(_ava|_geo|_com)[0-9]+$|(_c|_val|_previous)$)"){
name
email
username
}
}
Adrian
12/01/2021, 10:06 PMAdrian
12/01/2021, 10:11 PMAdrian
12/01/2021, 10:15 PMDaniel De La Luz
12/02/2021, 12:37 AMsatoshi
12/02/2021, 4:37 AMAdrian
12/02/2021, 8:00 AMPavel Savva
12/02/2021, 8:37 AMselect * from table where lower("columnName") = 'value';
? I have an index on lower("columnName")
. I've tried
where: {
columnName: {
equals: 'value',
mode: 'insensitive'
}
}
, however it results in a full database scan. The documentation links the Postgres page that suggests indexes on lower()
to achieve case insensitive searches, however, I can't figure out how to use lower()
in the where
clause of Prisma find.
I'm using Postgres and Prisma 2.joao.santos
12/02/2021, 11:45 AMquery users {
users(clinicNif: 111111111) {
id
email
name
companies{
id
fiscalName
fiscalNumber
email
}
}
}
whan I do this I get the include, but when I do this:
query users {
users(clinicNif: 111111111) {
id
email
name
}
}
The include is not in the query avoiding the 2 table query...
I've tried getting this done checking the query in the context, and acting accordingly, but it doesnt work very well... Thx in advancedDaniell
12/02/2021, 11:53 AMimport { config } from "./config"
which causes CustomError: Cannot find module '/workspace/prisma/config' imported from /workspace/prisma/seed.ts
with the following script:
"seed": "node --experimental-specifier-resolution=node --loader ts-node/esm ./prisma/seed.ts"
Adrian
12/02/2021, 11:56 AMconst user = {
name: 'Max',
profile: {
address: 'Frankfurt'
}
}
prisma.user.create(user)
makes way more sense than
const user = {
name: 'Max',
profile: {
create: {
address: 'Frankfurt'
}
}
}
prisma.user.create(user)
It's fairly logical that if profile has an "id" (primary key) then it should "connect" the entities instead (exactly what TypeORM does)