Stream: implementers
Topic: Conditional Delete Issue
Grahame Grieve (Jul 21 2016 at 23:30):
Query about GF#8779. The resolution this task proposes means that there will no longer be any way to find out whether you deleted something when you delete it
Grahame Grieve (Jul 21 2016 at 23:31):
given the ferocity with which some implementers claimed that they needed to be able to do that, taking it away makes me nervous
Grahame Grieve (Jul 21 2016 at 23:31):
the ask dispostion says "Since this is a breaking change we will consult the community about this change." - well, I can't see that this happened anytime, so here you are... the community is being consulted
Stephen Royce (Jul 22 2016 at 01:57):
I'm not familiar with the issue so this may be off-beam, but shouldn't there be an AuditEvent? If there was, then you know that the thing had been deleted.
Lloyd McKenzie (Jul 22 2016 at 02:19):
The client doesn't necessarily have access to the audit log, nor do they want to query it to determine if their operation succeeded or not
Stephen Royce (Jul 22 2016 at 03:10):
I'm unclear why the client would need to query the audit log to determine that. The client should simply ask the server "Did my operation succeed?" and the server would use whatever means necessary, presumably including querying the audit log, to answer the question.
Grahame Grieve (Jul 22 2016 at 03:21):
how does the client ask that? how do they refer to an operation when they ask that?
Stephen Royce (Jul 22 2016 at 03:28):
I don't know; @Lloyd McKenzie was the one who said they need to determine if the operation was successful or not. If you need to know that, then you need to have a mechanism to ask the server if it was, not try to figure it out on your own.
Grahame Grieve (Jul 22 2016 at 03:29):
right now, the server just tells you directly. That's being proposed to be removed
Stephen Royce (Jul 22 2016 at 03:33):
Then I would suggest you either do not do that or you provide a query operation that the client can use to ask about the operation after the fact; I definitely would not rely on clients being able to determine for themselves if an operation was successful or not.
Grahame Grieve (Jul 22 2016 at 05:12):
I'll take that as a vote that you think that a client needs to be able to know
Stephen Royce (Jul 22 2016 at 05:20):
Not necessarily. I don't really have enough experience with this to vote one way or another; I'm just saying the _if_ you want the client to know, don't make them work it out for themselves. Having said that, I find it hard to imagine that a 200 response would not be enough acknowledgement of success, but I'm not working with complex transactions.
Stephen Royce (Jul 22 2016 at 05:29):
Okay; so I just actually read the issue again, and I agree that the client does need to be able to know and that returning a 404 response is not really a good idea. To my way of thinking, successfully deleting no records is still a success and it's more important to know that there was no failure than that there were no records deleted. Of course, the response could contain a deletion count, but not sure how that might affect the specification.
Stephen Royce (Jul 22 2016 at 05:30):
So I support the resolution.
Richard Ettema (Jul 22 2016 at 13:07):
After reviewing the tracker item for this, I see that the resolution is to simply modify the returned response code in the specific case of a conditonal delete operation not matching any resources to now return a 204 (No Content) instead of the 404 (Not Found). This change provides consistent behavior with the delete operation when the resource to be deleted does not exist at all.
Richard Ettema (Jul 22 2016 at 13:07):
So, I also support the resolution.
Grahame Grieve (Jul 24 2016 at 07:32):
ok, made the change
Angus Millar (Nov 21 2016 at 12:04):
I just implemented Conditional delete alowing for the delete all the matching resources. But then I thought about the consequences of this operation and it got me worried. If a client sends delete operation such as DELETE [base]/Patient then all patient records will be deleted, sounds dangerous, it's only a slip away from GET all Patient resource. And even worse if some sends an incorrect search parameter i.e DELETE [base]/Patient?identiphier=http://acme.org/patient|23 then the unknown search parameter will be ignored and once again all Patient resource deleted.
In light of this, I want to implement conditional delete whereby zero search parameters or any unknown search parameters returns 412 - Precondition Failed. Does this sound fair?
Grahame Grieve (Nov 21 2016 at 19:52):
yes
Angus Millar (Nov 21 2016 at 23:31):
Thanks Grahame
Brian Postlethwaite (Nov 23 2016 at 05:53):
While we're on the conditional subject, the spec is quiet on what should happen if the resource instance PUT to the conditional update has an id in it (and clashes with the one that comes back from the call)
Should I report a bad request (like I do when POST is used, or PUT without)
Grahame Grieve (Nov 23 2016 at 05:57):
that's changed; we should provide guidance, and it should be cosistent (ignore and overwrite)
Brian Postlethwaite (Nov 23 2016 at 05:59):
So ignore rather than fail (like we do with a POST that has the Id inside)
Brian Postlethwaite (Nov 23 2016 at 06:00):
And with the delete, the spec is pretty clear that if your server only wants to permit single record conditional deletes, that's perfectly normal.
Angus Millar (Nov 23 2016 at 07:16):
(from the FHIR spec) Update PUT:
The request body SHALL be a Resource with an id element that has an identical value to the [id] in the URL. If no id element is provided, or the value is wrong, the server SHALL respond with a HTTP 400 error code, and SHOULD provide an operation outcome identifying the issue.
(from the FHIR spec) Create POST:
The request body SHALL be a FHIR Resource. The resource does not need to have an id element (this is the one of the few case where a resource exists without an id element). If an id is provided, the server SHALL ignore it.
Condition Update PUT:
So when the resource does have and id and it does not match the located resource's id (located by search) we are in a 50/50 decision. Do we behave like a Create or like an Update. Create would ignore the id whereas Update would reject it. I would argue that a Condition Update should behave live an Update. A normal Create can ignore the id as there is no conflicting id's, yet Condition Update can detect the conflict in ids and should report it, not ignore it.
Michael Lawley (Dec 09 2016 at 05:35):
+1 @Angus Millar Update (conditional or otherwise) needs to be more conservative than Create
James Agnew (Dec 09 2016 at 18:54):
This is how HAPI's server works by default FYI
Last updated: Apr 12 2022 at 19:14 UTC
