Conversation
- adding version match for overwrite - testing locking - generated tests (not implemented)
|
drafted until the rest of the stack is updated |
…the-version-they-are-overwriting-has-changed
The expressError handling was turning this into a text error with no payload, just a message
|
Ready for Review. This considers incoming requests on the /overwrite path and reads the On a 409 error, the This change does not require any change to Services, Tiny, or Interfaces, but will never 409 until the downstream chain is in place. The one exception is that a user absentmindedly sending a complete object with a There is a PR that implements this in TinyPen, but not TinyThings yet. |
thehabes
left a comment
thehabes
left a comment
There was a problem hiding this comment.
The test files are just .txt files, but if they are something you want to have run you can try them as .js files. You could just leave them as TODO unless you want to save the notes.
Consider moving the check for __expectedVersion into __rerum
| } catch (error) { | ||
| next(createExpressError(error)) | ||
| // Optimistic locking check - no expected version is a brutal overwrite | ||
| const expectedVersion = req.get('If-Overwritten-Version') ?? req.body['__expectedVersion'] |
There was a problem hiding this comment.
I think we check for this property in __rerum. That way we are not making __expectedVersion a reserve key on the payload body. What if I am legitimately trying to overwrite my object to be
{
"name": "Bryan",
"__expectedVersion": "good"
}
thehabes
deleted the
197-overwrite-does-not-notify-requestors-if-the-version-they-are-overwriting-has-changed
branch
2 participants
To use:
__rerum.isOverwrittenproperty or include this property in the request (it will be discarded as usual, so it can be partial)error.currentVersionwill supply the current version for a quick retry if you can easily diff what changes you would like.