Stream: hapi
Topic: Cascading Delete
James Agnew (Jun 28 2019 at 20:57):
Hi All,
So, lots of people have been asking for a cascading delete function in HAPI FHIR lately ( @René Spronk @Sean McIlvenna @David Hay ).. This is now available on the public HAPI FHIR server, and will be available as an optional interceptor in the JPA server by this weekend.
Do do a cascading delete, add _cascade=true do your HTTP DELETE URL.
David Hay (Jun 28 2019 at 21:12):
Cool! And the CLI?
Paul Lynch (Jun 28 2019 at 21:47):
Is that standard FHIR, or a HAPI extra?
René Spronk (Jun 29 2019 at 05:23):
Thanks - just as a point of clarification: if used on e.g. Encounter/123, this would delete the encounter as well as any resources referencing the encounter, expanding the tree to anything that somewhere in the tree structure directly or indirectly references Encounter/123?
James Agnew (Jun 30 2019 at 14:42):
@David Hay - Yup it'll be supported in the CLI
@Paul Lynch - This is a HAPI specific feature. I think HAPI is one of the few that enforces referential integrity in the first place so most wouldn't need this feature anyhow.
@René Spronk - That's how it should work, yup. Definitely welcome any feedback if it's not doing what you expect.
James Agnew (Jun 30 2019 at 14:45):
Oh, and this has been merged to master not for anyone who wants to try it on their own server - This is the interceptor in question: https://github.com/jamesagnew/hapi-fhir/blob/master/hapi-fhir-jpaserver-base/src/main/java/ca/uhn/fhir/jpa/interceptor/CascadingDeleteInterceptor.java
Man, I can not tell you how much I love the new interceptor framework. It is so cool for this kind of thing. We have Ken Stevens to thank for most of the hard work on this feature.
René Spronk (Jul 01 2019 at 08:33):
Postman, trying to exec DELETE http://hapi.fhir.org/baseDstu3/Patient?identifier=1020304050&_cascade=true - error 409 Conflict, OperationOutcome states "Trying to delete Condition/1686707/_history/1 but this is not the current version"
James Agnew (Jul 01 2019 at 16:20):
Ah thanks for letting me know, will investigate.
FYI I have changed the syntax slightly, so you now need to do _cascade=delete (not true). It occurs to me that there are plenty of other behaviours that might also make sense, so a more flexible syntax is better, even if we only support one option right now.
James Agnew (Jul 02 2019 at 09:41):
@René Spronk This bug has been (hopefully) fixed
René Spronk (Jul 02 2019 at 09:53):
Works like a charm. Side observation during testing: using a GET for Patient?_tag=http://www.alpha.alp/use-case| (i.e. no code supplied) produces an error - can't search for 'any tag from a particular coding system' , code is mandatory. Why is that?
James Agnew (Jul 02 2019 at 09:57):
We don't have indexes in the DB to support that search, nothing more interesting than that. Could definitely add if there is a usecase.
René Spronk (Jul 02 2019 at 10:13):
No particular use case here - during FHIR training courses we ask people to update the patient name in an instance example, and sometimes they modify the tag-value as well (it has the same value as the patients' given name). But there are different ways of dealing with that issue when deleting these training resources from the public test servers (mostly either HAPI or Vonk for the STU3 exercises, we'll reselect the appropriate open test servers for our R4 exercises which we'll start using this September, I'm fairly sure HAPI and Vonk will still be part of our list though - especially now that cleaning up has gotten easier on HAPI than it was before).
Last updated: Apr 12 2022 at 19:14 UTC
