Support client opt-in for skipping the update if a resource hasn't changed #2263
Assignees
Labels
Milestone
Comments
lmsurpre
added a commit
that referenced
this issue
Apr 22, 2021
1. add a skippableUpdate flag to the FHIRResourceHelpers interface 2. set this flag from a new header X-FHIR-UPDATE-IF-MODIFIED 3. if skippableUpdate is true, use the resource fingerprinter to compare the resource from the update request to the resource in the database and skip the update when they match Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre
added a commit
that referenced
this issue
Apr 22, 2021
|
Verified this with @lmsurpre using Postman. |
This was referenced Apr 24, 2021
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 scenarios where the FHIR Server is not the source of truth, some clients might want to reload/refresh the server with their data on some nightly basis.
For severs that don't supporting versioning, you can basically just replace the old data with the new data and be done.
IBM FHIR Sever doesn't support this mode...we always write a new version of a resource when we receive a PUT.
Currently, to avoid unneccessary PUTs, clients will need to either keep track of what has been uploaded or perform a read before they perform their updates.
What would be nice is if we could build that logic into the server and avoid performing the update when the resource contents havn't actually changed. This would avoid the cost of historical versions filling up the database and obviate the need for some kind of historical version cleanup.
The other behavior of a PUT is that we re-extract all of the search parameters.
Because skipping the update would also skip this part, I think it would be best to force users to opt-in to this special no-op "fast update".
Describe the solution you'd like
Allow users to pass a special header, maybe X-FHIR-UPDATE-IF-MODIFIED, to opt into this special optimization. When present (and with a value of "true"?), perform a comparison of the prior version of this resource with the new version that was just sent in.
Unfortunately, we can't do a normal equals, because we want to explicitly ignore the server-assigned Resource.meta.lastUpdated and Resource.meta.versionId fields.
Describe alternatives you've considered
At some point in the future (probably after we get #2155 in place), it would be neat to automatically convert a PUT with no content change into a reindex. Then, based on the proposal in #2155 we would skip the reindex if the extracted parameters havn't changed either.
Acceptance Criteria
1.
GIVEN an existing resource in the server
WHEN we get an update request
AND the X-FHIR-UPDATE-IF-MODIFIED header is set to true
THEN avoid performing the update
AND return the existing resource as appropriate (per the
Prefer: returnrequest)Additional context
Similar, but different, from #2050
The text was updated successfully, but these errors were encountered: