`SELECT FOR UPDATE`
## Problem To avoid mid-air-collisions in REST there are two primary techniques: **Last-Modified / If-Unmodified-Since**, and **ETags**. Prisma makes it extremely difficult to support these techniques. There is no concept of `SELECT FOR UPDATE`, which is required to ensure that nothing issues an **update** underneath me while I am verifying the **@updatedAt** value for **If-Unmodified-Since**, or the hash of the **select** results if I am using **ETags**. ## Suggested solution I would recommend a solution that uses a callback. This is just one idea. It would create a transaction and use a FOR UPDATE on the SELECT if it detects an 'update' or 'delete' property. My callback is placed in 'update.before', as to not pollute the root property list. If my callback throws, the transaction is broken and we are done. If it goes through, we issue the update... or delete. It could look like this: ```javascript // My own custom 'middleware' allowing me to do what ever I'd like before the update. const myCallback = result => { if (!result) { throw new HTTPException(204, 'No Content'); } if (result.updatedAt > myLastModifiedDate) { throw new HTTPException(412, 'Record has been modified'); } }; prisma.user.findUnique({ where: { id: id }, select: { updatedAt: true }, update: { before: myCallback, data: myUpdatedData } }); ``` ## Alternatives There may be a number of ways one could accompl
Posted by brandonmpetty on Aug 4, 2021, 6:18 PM
Tags
Related issues
- The issue is really the extreme difficulty of programming them, especially for anything sequential (rather than combinatorial).
- I probably could have beared with it if it was only limited to programming, but it showing up in creative fields has made me feel all sor...
- I hate that I'm in deep enough to know what you mean.
- The biggest problem with “AI” is that big corps are shoving it down our throats.
- in the middel of a coding session with 5.6 sol.
- [Hero Run] 535B-A23B on 18T tokens
Raise real-world problems, find people facing the same issue, and discuss solutions.3,000 issues0 comments
reliability (Other)
The issue is really the extreme difficulty of programming them, especially for anything sequential (rather than combinatorial).
I probably could have beared with it if it was only limited to programming, but it showing up in creative fields has made me feel all sor...
I hate that I'm in deep enough to know what you mean.
The biggest problem with “AI” is that big corps are shoving it down our throats.
in the middel of a coding session with 5.6 sol.
[Hero Run] 535B-A23B on 18T tokens
I hate that this is how AI is being used..
inexperienced protobuf user here -- why do non-googlers generally use protobuf?
`SELECT FOR UPDATE`
## Problem To avoid mid-air-collisions in REST there are two primary techniques: **Last-Modified / If-Unmodified-Since**, and **ETags**. Prisma makes it extremely difficult to support these techniques. There is no concept of `SELECT FOR UPDATE`, which is required to ensure that nothing issues an **update** underneath me while I am verifying the **@updatedAt** value for **If-Unmodified-Since**, or the hash of the **select** results if I am using **ETags**. ## Suggested solution I would recommend a solution that uses a callback. This is just one idea. It would create a transaction and use a FOR UPDATE on the SELECT if it detects an 'update' or 'delete' property. My callback is placed in 'update.before', as to not pollute the root property list. If my callback throws, the transaction is broken and we are done. If it goes through, we issue the update... or delete. It could look like this: ```javascript // My own custom 'middleware' allowing me to do what ever I'd like before the update. const myCallback = result => { if (!result) { throw new HTTPException(204, 'No Content'); } if (result.updatedAt > myLastModifiedDate) { throw new HTTPException(412, 'Record has been modified'); } }; prisma.user.findUnique({ where: { id: id }, select: { updatedAt: true }, update: { before: myCallback, data: myUpdatedData } }); ``` ## Alternatives There may be a number of ways one could accompl
Comments (0)
No comments yet. Start the discussion.