-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OnInsert/OnUpdate hooks can modify the new resource item, Etag not recalculated #255
Comments
Let's try to find a few problem cases, to see how they are handled by any given solution: E.g. what happens if:
|
Okay, if you are referring to the invisible
However if you are including your own: |
I am referring to when you include your own field; or indeed any other field that is generated (by a field or resource hook) on update. Another important question is:
The reason for coming up with these cases is to see which one we want to priortize before settling on the exact solution; there are trade-offs we can do to prioritize the most important use-cases if we can figure out which ones that is. |
Example trade-off:
We can avoid this by aborting the update if there are no changes to a resource after a patch or put operation. Trade-off: It won't be possible to force resource updates (via hooks) by updating (without changing) a field value. What ever we end up on, the solution must of course be documented. Writing the documentation will also be a good test for the solution; if we can't easily formulate the behaviour in words, probably our solution is too complex. |
In my opinion, force update via HTTP call should be counted as "update" even if we don't change anything in the resource item. Think of If one doesn't want that behavior, then he should make his own hook that can be executed last, that should inspect all relevant fields, and if no changes there, he can just make Sadly we can't modify HTTP response from hooks, so one can return 304 if no changes. |
OK, let's go with this for now then; it sounds easier to document. The only feature I can think of where an early abort sounds useful, is for list PATCH operations, but that isn't a feature that we currently got. We can revisit it at that point. The remaining question is then, is there a case for updating the E-tag between each hook (e.g. to check for changes between original and item), or is updating of the E-tag right before storing the resource sufficient? |
I think updating right before storing is just fine for now. Will make a PR today or tomorrow. |
E-tags used to be set after parsing an item only, before potential hooks alter the item content. This change adds a final step to resource Update and Create operations to recalculate E-tags right before passing items to the Storer back-end. Fixes rs#255
During POST/PUT/PATCH new resource item Etag generation is done in
item, err := resource.NewItem(doc)
from the document supplied from the request. However after that hooks will be applied, that may or may not modify this item further. Modifying the item in the hook, doesn't recalculate the Etag.One obvious solution suggested by @smyrman , is moving Etag calculation right before hitting the Store.
The text was updated successfully, but these errors were encountered: