https://www.prisma.io/ logo
Join Slack
Powered by
Hello everyone guys. I had a fear that the `upsert...
# orm-help
m
Hello everyone guys. I had a fear that the 
upsert
is non-transactional. After completing many 
upsert
asynchronously, one of the call fell with a uniqueness error. That is, as I understand it, the prisma first run a select, and there is no record. Then value from other call writing down in a DB, after that the prisma tried to write down value, believing that it is not present in a DB that ended with an error Is this expected behavior? If so, can this point be recorded in the documentation? And the main question - how can we simulate an 
upsert
transactionally?
r
@Mykyta Machekhin 👋 
upsert
is transactional as you can see by enabling the query log and in the screenshot I posted:
Copy code
const prisma = new PrismaClient({
  log: ['query'],
})
Also dynamically inserted values:
Copy code
const users = [1, 2, 1, 4, 5].map((val) =>
    prisma.user.upsert({
      create: { email: `user${val}`, name: `user${val}` },
      update: { name: `user${val}` },
      where: { id: val },
    })
  )

  await Promise.all(users)
m
I read logs from the very beginning of development, but when there are too many requests at the same time, the line with start of transaction turns out detached from a line of the request, mixing other logs. Because of this, real transactions cannot be traced. Thanks for the reply! Now I understand. At the same time, you can explain how the DB can give out an error of uniqueness on that set of fields which is listed in property where in an 
upsert
(checked several times that it is that set of fields)
unfortunately now we have solved this problem with a crutch on production therefore I do not have an opportunity to show the screen
r
I don’t know where the uniqueness error came from. If you could provide a small reproduction then it would be great 😄
Open in Slack
PreviousNext
Powered by