Comments (7)
I think updating right before storing is just fine for now. Will make a PR today or tomorrow.
from rest-layer.
Let's try to find a few problem cases, to see how they are handled by any given solution:
E.g. what happens if:
- A resource with an
updateAt
timestamp field is PATCHED with no changes. Is the resource (and hence the E-tag) updated?
from rest-layer.
Okay, if you are referring to the invisible _updated
field, that is produced by rest-layer
then no, it is not included in the Etag sum.
func NewItem(payload map[string]interface{}) (*Item, error) {
id, found := payload["id"]
if !found {
return nil, errors.New("Missing ID field")
}
etag, err := genEtag(payload)
if err != nil {
return nil, err
}
item := &Item{
ID: id,
ETag: etag,
Updated: time.Now(),
Payload: payload,
}
return item, nil
}
However if you are including your own:
"updated": schema.UpdatedField,
, I am afraid it is a modification.
from rest-layer.
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:
- Is there any cases where it's important for a hook to get an updated/accurate E-tag? (can't think of any myself)
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.
from rest-layer.
Example trade-off:
However if you are including your own:
"updated": schema.UpdatedField,
, I am afraid it is a modification.
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.
from rest-layer.
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 touch
semantics.
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 item=original
and revert all changes, including any "updatedAt" fields, etc.
Sadly we can't modify HTTP response from hooks, so one can return 304 if no changes.
from rest-layer.
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 touch semantics.
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?
from rest-layer.
Related Issues (20)
- Remove old sub-resource syntax HOT 4
- go module: cannot find module providing package testing/mem HOT 3
- Explicit $eq in filter passes whole predicate to Validate(Query) HOT 3
- `Prefer: return=minimal` can hide resource item on server modification HOT 12
- Consistent empty / null fields HOT 4
- Remove resource hooks in favor of resource middleware HOT 12
- Newest `zerolog` versions cause a panic HOT 4
- Bogus error line, when returning empty response on 204
- Etag should not depend on external state HOT 4
- Assist AutoIncrement FieldValidator with SQL backend HOT 8
- How use schema and resource package as standalone HOT 1
- Bulk PATCH support HOT 5
- Wrapping original issue in rest.Error HOT 7
- Feature Request: Cursor-based Pagination HOT 3
- pq: operator does not exist: uuid ~~ unknown HOT 7
- Filter on reference fields HOT 1
- Support for $not filter operation HOT 4
- Decouple ElemMatch from schema.Array struct
- openapi 3.1.0 support HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rest-layer.