Hi guys. I found out that data modify methods (`.c...
# orm-help
m
Hi guys. I found out that data modify methods (
.create, .update
etc) are not work at all if I don’t use
await
,
.then
or
.catch
on this methods. Can someone explain me why is it?
a
That's more a Javascript thing than a Prisma thing
basically, if you don't include await, you're basically saying "This is a set of instructions to get data from the database."
By either including await or calling the .then() method, you're saying "please actually do these instructions, and let me know when you have results."
s
Conceptually, what you are
await
-ing from Prisma is confirmation that something happened during your CRUD operation. Which can be success or failure. For example, if you wanted to say “Prisma, add a
Widget
to the database with an id of `123`”, how would you feel if it added the Widget but then didn’t tell you anything? This way, when you ask Prisma to do something, it tells you what happened by saying “Here is proof from the database that I did what you said”. In other words, when you declare:
Copy code
const body = await prisma.widget.create({
  data: {
    id: 123
  }
});
in most frameworks, this happens within a function where you return a
status
and a
body
. The
body
that is returned is proof that Prisma did its job, and the Widget you asked to be created exists in the database.
Of course,
body
may also be an error message if something went wrong.
n
Database operations that you would be doing through prisma would be asynchronous so you would need to
await
them. This description of when to use await was helpful for me, should be helpful to you as well
m
@Austin Zentz The fact is that ordinary asynchronous functions are executed regardless of whether there is or not a result handler. Only with a prisma I see such that if there is no handler, then the function is not executed at all. This is not quite normal behavior for javascript. If a database operation not performed after a function call, it’s more like a query builder. The main problem here is that if the developer for some reason forgot to attach a handler to a function, he will never know that the function was not executed. Since when errors occur in asynchronous functions without handlers, we catch them at the application level through uncaughtException. But in our case, no error will occur, since the operation is not performed. For me it was a revelation. And now it requires manual analysis of the entire application code for the presence of prism function calls without handlers