-
Notifications
You must be signed in to change notification settings - Fork 156
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
Make skippable updates the default #3614
Labels
enhancement
New feature or request
Comments
lmsurpre
added a commit
that referenced
this issue
May 3, 2022
Replaced the old "X-FHIR-UPDATE-IF-MODIFIED" header with a new "X-FHIR-FORCE-UPDATE" one. The default is still false, but now that means that no-op updates are now skipped by default. To force the server to perform a no-op update, users must now explicitly set this X-FHIR-FORCE-UPDATE header to true. Signed-off-by: Lee Surprenant <[email protected]>
lmsurpre
added a commit
that referenced
this issue
May 3, 2022
Previously we just passed the value to FHIRPersistence and let it handle this. We still need FHIRPersistence to double-check it (in case of a race), but we should be able to handle the simple case up-front from the REST layer. The real motivator for this change is that we compute "skippable updates" in the REST layer *prior* to passing it to FHIRPersistence and I wanted to check the precondition before we perform that optimization. Signed-off-by: Lee Surprenant <[email protected]>
lmsurpre
added a commit
that referenced
this issue
May 3, 2022
Replaced the old "X-FHIR-UPDATE-IF-MODIFIED" header with a new "X-FHIR-FORCE-UPDATE" one. The default is still false, but now that means that no-op updates are now skipped by default. To force the server to perform a no-op update, users must now explicitly set this X-FHIR-FORCE-UPDATE header to true. Signed-off-by: Lee Surprenant <[email protected]>
lmsurpre
added a commit
that referenced
this issue
May 3, 2022
Previously we just passed the value to FHIRPersistence and let it handle this. We still need FHIRPersistence to double-check it (in case of a race), but we should be able to handle the simple case up-front from the REST layer. The real motivator for this change is that we compute "skippable updates" in the REST layer *prior* to passing it to FHIRPersistence and I wanted to check the precondition before we perform that optimization. Signed-off-by: Lee Surprenant <[email protected]>
lmsurpre
added a commit
that referenced
this issue
May 4, 2022
Previously we just passed the value to FHIRPersistence and let it handle this. We still need FHIRPersistence to double-check it (in case of a race), but we should be able to handle the simple case up-front from the REST layer. The real motivator for this change is that we compute "skippable updates" in the REST layer *prior* to passing it to FHIRPersistence and I wanted to check the precondition before we perform that optimization. Signed-off-by: Lee Surprenant <[email protected]>
Verified this is now the new default, closing issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
In #2263 we added opt-in support for skipping updates when the the resource content matches the existing resource content.
This seems to be working well, but most clients don't know to opt in for this.
Describe the solution you'd like
There seems to already be broad support for this idea in the community (e.g. https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Handling.20of.20Updates/near/270802907 ) and so I think we could remove the client opt-in and just make this the normal behavior for 5.0.
I'm thinking that we retire the custom
X-FHIR-UPDATE-IF-MODIFIED
header (the name was confusing anyway) and always skip the update in this case, but I'd also be fine with renaming the header to something likeX-FHIR-FORCE-UPDATE
(with a default of false).Describe alternatives you've considered
Make it configurable via a server config property instead.
Acceptance Criteria
GIVEN a patch or update
AND the updated resource matches the existing one (sans Resource.id, meta.versionId, and meta.lastUpdated)
WHEN HTTP header
X-FHIR-FORCE-UPDATE
is absent or set to "false"THEN the update is skipped
GIVEN a patch or update
AND the updated resource matches the existing one (sans Resource.id, meta.versionId, and meta.lastUpdated)
WHEN HTTP header
X-FHIR-FORCE-UPDATE
is set to "true"THEN the update is performed
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: