Stream: implementers
Topic: vread Current vs versioned resource
Paul Watt (May 10 2018 at 23:37):
Hi All, If querying a resource using a vread is there anything in the resource that indicates that the returned version is not the current version? I note that there is resource.active but the description appears to be functional - ie this record is active vs the version of the record resource is not active. Is there somewhere else that indicates this for the resource version?
Lloyd McKenzie (May 11 2018 at 12:45):
The 'active' flag only exists on Patient (and perhaps one or two other resources) and it applies to the record, not the version. I'm not clear what the point of a declaration on resource that says "this is the current version" would be, given that such a claim could be invalidated milliseconds after it was retrieved. Can you explain how you'd use such a flag?
Paul Watt (May 14 2018 at 01:20):
Maybe it's not significant but my thought process was if a client queried using a vread and the server returns the current version how does the client know that it's the current version? (without necessarily querying the same resource with a read) Alternatively if a server received a vread that is for the current version should it just return the current version or should it return something else such as a redirect to the read?
Lloyd McKenzie (May 14 2018 at 05:18):
If a server receives a vread, the expectation is that it will receive a response back, not a redirect. Typically a server either wants "most recent" or "the version as it was referenced". The knowledge of what's "current" is highly dynamic.
Paul Watt (May 14 2018 at 06:18):
So a vread that happens to be the most recent version is simply returned to the client.
Given that current is dynamic is there anything that flags to a client that a historical version has been returned?
Lloyd McKenzie (May 14 2018 at 06:38):
Not right now. Again, the question would be what the use-case is for the flag given that the absense of the flag doesn't mean that your version is still "current".
Grahame Grieve (May 14 2018 at 07:07):
I'm not sure why it should matter that a historical version is also current?
Jens Villadsen (May 14 2018 at 07:29):
All versions are historic to a client to any extend. The resource that a client 'just' received can be outdated the millisecond after. As such, the server would tell the client a lie if it said it was the current version - it can only be the newest within that split of transaction. It might have been the newest version retrieved at the time of the client request - but that 'newest' version can be stale right after you fetched it. Since it sounds like you are using versioned resources and that you will probably update your resources based on its version (which is great) you will probably encounter the version aware updates scheme - and you will know for sure if your resource is stale or not.
Paul Watt (May 14 2018 at 10:50):
I agree with the arguments around not flagging a current version. The thought came up when working through vread on how to minimize the potential risk of action being taken on a stale resource - either know it's the most current or that it's not, given that a vread could potentially return either.
Jens Villadsen (May 14 2018 at 10:53):
If you support the use of http://build.fhir.org/http.html#versionaware you should not hit the case of running updates on stale data.
Paul Watt (May 14 2018 at 11:09):
Agreed updates are covered with IfMatch checking. The action I was talking about was clinician action rather than a system action.
Lloyd McKenzie (May 14 2018 at 11:52):
If it's relevant, the system can do a GET on the base URL looking for a response only if the data has changed eTag. If you get a response, you've now got the current version and if nothing's changed, you haven't cost yourself much bandwidth.
Jens Villadsen (May 14 2018 at 18:19):
@Lloyd McKenzie - if you're looking for performance then use the HTTP HEAD operation in combination with ETag. It saves you the body
Jens Villadsen (May 14 2018 at 18:20):
@Paul Watt Ain't it more a task for the software to do such checks and verifications?
Lloyd McKenzie (May 14 2018 at 18:37):
Yes, but if you want to make sure you have the current version, you'd actually want the full payload if there is one
Jens Villadsen (May 14 2018 at 20:18):
Ain't that what HEAD and ETag is all about? Not specifically load and serialize the entire resource but just checking the version?
Lloyd McKenzie (May 14 2018 at 20:58):
Right. But if your problem is "I have some version and want to know if I have the current version before I update", then you'll always want to actually retrieve the current version if you don't already have it. So far we haven't heard a use-case to just check whether I've got the current version, but have no interest in retrieving the current version if I don't have it. If there were such a use-case, then HEAD + ETag would be the solution.
Jens Villadsen (May 14 2018 at 21:06):
@Lloyd McKenzie - Performance ... thats your reason. And the fact that you can flag parts of your model as guaranteed outdated. If your resources are costly to transfer because of size or whatever other reason, then it is a perfectly valid reason for using just HEAD and ETag. And usually, performance ain't fit to model as use cases, IMHO.
Lloyd McKenzie (May 14 2018 at 21:13):
Yes - but if you need the current version to update, you're going to then have to query for the current version anyhow, so haven't saved yourself anything.
Paul Watt (May 14 2018 at 22:41):
@Paul Watt Ain't it more a task for the software to do such checks and verifications?
Yes, could definitely pass on the responsibility to the client application.
Jens Villadsen (May 14 2018 at 22:52):
@Lloyd McKenzie Right ... but if the operation is costly you might want to postpone that, and updates to that resource. You can simply mark it for later retrieval at the point of when you need to update it and not before that.
Brian Postlethwaite (May 15 2018 at 11:31):
better to retrieve the current version with the if-modified-since header.
http://hl7.org/fhir/http.html#cread
This does what you're looking for, returns you content if its changed, otherwise like the head.
Jens Villadsen (May 15 2018 at 21:59):
and thats why one can only love these open forums because eventually an awesome response pops up - @Brian Postlethwaite +1
Last updated: Apr 12 2022 at 19:14 UTC
