Stream: implementers
Topic: Breaking Change Alert!
Grahame Grieve (Mar 23 2016 at 06:13):
Task 8779 (http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=8779&start=50) says that the result of a conditional delete that fails should be changed from a 404 to a 204.
Grahame Grieve (Mar 23 2016 at 06:13):
it also says: "Since this is a breaking change we will consult the community about this change."
Grahame Grieve (Mar 23 2016 at 06:13):
well, here you go, being consulted
Grahame Grieve (Mar 23 2016 at 06:15):
I have a problem with this - it's the only way to find out whether a delete happened or not. It was deliberately different so you could tell whether it succeeded or not
Grahame Grieve (Mar 23 2016 at 06:15):
@James Agnew - comment from you...
James Agnew (Mar 23 2016 at 09:16):
I'd say it succeeded if all matching resources were deleted. The fact that there were 0 or 100 matches doesn't change the fact that it was a success.
Is there a use case for wanting to do a conditional delete but needing to know that it didn't find any matches? The use case for the opposite is Simone's work around turning V2 messages with allergy lists into transactions, which seems valid to me
Grahame Grieve (Mar 23 2016 at 10:16):
Well, I think that users see a comfort factor in knowing that something was deleted or not. They know whether they got the Target details correct
Jason Walonoski (Mar 23 2016 at 12:10):
Let's recap... is the proposal this?
Conditional Delete
- No Matches Server returns
204 No Content - One Match Server deletes the match and returns
204 No Content - Multiple Matches Server returns
412 Precondition Failed
In this case, you can't differentiate between no match and one match.
Grahame Grieve (Mar 23 2016 at 12:12):
yes that's the proposal. One of the goals of introducing conditional delete was to allow a client to know whether delete happened or not. transactionally. (as opposed to simple delete). THis proposal would mean you couldn't find at that way either
Pascal Pfiffner (Mar 23 2016 at 15:24):
I'd agree that a no matches should not be an error, i.e. < 400. From a client perspective I don't think I'd care how many things were deleted (even if zero) since I just want to be sure they are gone in case they are there. If I get a 404 I'm assuming something went wrong, I'd handle the error simply to discover that nothing needed to be deleted.
Otherwise, if I cared, I could first search for them and then individually delete them. Or an OperationOutcome could be returned?
Grahame Grieve (Mar 23 2016 at 19:14):
Pascal, that is not transactionally safe. If you simply want to delete, you can use the normal delete operation, that works as you say. Conditional delete was imagined as a way to find out whether you deleted or not
Grahame Grieve (Mar 23 2016 at 19:14):
I suppose we could profile OperationOutcome, yes. but it seems ways more complex.
Grahame Grieve (Mar 23 2016 at 19:14):
I'm not sure what the driver for this change is?
Pascal Pfiffner (Mar 23 2016 at 21:01):
I guess I interpreted the target use case for the conditional delete wrong, then. The change request mentions “This means that you can't have a transaction which deletes a collection of AllergyIntolerances for a patient and replaces it with a new list”. I can see how in this case a 404 is suboptimal.
I'd have thought along the same lines, e.g. an app that for whatever reason needs to replace a month's worth of glucose readings with values from another source. I'd see how you can do a conditional delete and don't actually care whether zero or 1,345 readings were deleted, you just want to be sure all those are gone.
If the idea is to only delete one certain resource I'd go the other route and search for it first, then delete if it exists. I'm probably missing a common use case for this envisioned conditional delete, one match and you need to know whether this one match was deleted.
Grahame Grieve (Mar 23 2016 at 21:10):
"earch for it first, then delete if it exists" - transactional problem.
Grahame Grieve (Mar 23 2016 at 21:12):
I don't understand why 404 means you can't do that
Simone Heckmann (Mar 24 2016 at 14:06):
If a client wants to purge and replace Items in one transaction as Pascal describes, the fact that there was nothing to purge shouldn't cause the transaction to fail. The client would still want the new items to be added. I think the "purge and replace"-scenario is going to be very common. That's also why we changed the sequence of the transaction processing to DELETE-POST-PUT-GET .
Grahame Grieve (Mar 24 2016 at 18:29):
Ok. So a 404 means transaction fail... I'll think about that
Grahame Grieve (Mar 24 2016 at 19:52):
need a 209 deleted...
Pascal Pfiffner (Mar 25 2016 at 12:41):
Too bad there is no 2xx No Change nor the 209 Deleted indeed. Could change to a 200 OK and an OperationOutcome if one absolutely must know what was deleted, which I think is mostly needed when only 1 resource should be deleted, so one could just as well do a get/search first, then a delete.
I still think _conditional delete_ is for “delete anything that matches and let me continue”, so 204 No Content sounds good to me. If you need to know what was deleted, do a search and the standard _delete_. But my view is heavily biased on client side flows.
Grahame Grieve (Mar 25 2016 at 17:15):
Search and delete has transactional problems
Bryn Rhodes (Mar 25 2016 at 17:15):
Right, best case you'll get optimisitic concurrency failures, worst case, deadlocks.
Grahame Grieve (Mar 25 2016 at 17:16):
Best case it'll work! You're a pessimist?..
James Agnew (Mar 25 2016 at 21:27):
Back online after a few days of spotty wifi.. Could we solve this with a code in the OperationOutcome returned by the server? Like, the server could return an OO with a code of "MSG_NO_MATCH" if it didn't find anything to delete.
Grahame Grieve (Mar 25 2016 at 22:03):
We could. For me, it raises the question of defining content specific error magic values. There's been several other use cases for this, and I'm starting to see them in implementation guides. I don't know whether we should get I to that or not
James Agnew (Mar 25 2016 at 22:07):
Well, I mean it's kind of splitting hairs but to me this isn't an error condition.. It's just a clarification about the success.
I would see "just delete anything that matches this search and I don't care how many that is" as the most likely way this would be used...
Grahame Grieve (Mar 26 2016 at 00:34):
Agree. Error wasn't the right word. Special magic values for OperationOutcome.issue.details
Last updated: Apr 12 2022 at 19:14 UTC
