Stream: implementers
Topic: Transaction operations order
nicola (RIO/SS) (Mar 19 2019 at 20:01):
Operations in transaction bundle have explicit order. I'm still very curious why do we need to force this rearrangement by HTTP methods - https://www.hl7.org/fhir/http.html#trules? It can just puzzle users. As well for testing, I would like to run create, read, search and delete operations in transaction and rollback - why this is impossible?
Grahame Grieve (Mar 19 2019 at 20:34):
force this rearrangement by HTTP methods
Grahame Grieve (Mar 19 2019 at 20:34):
I'm not sure what that means
Grahame Grieve (Mar 19 2019 at 20:35):
Generally, we do not say that you cannot implemnent some kind of transaction manager, but we have agreed not to describe that as part of the core standard
nicola (RIO/SS) (Mar 19 2019 at 21:01):
I mean this
nicola (RIO/SS) (Mar 19 2019 at 21:02):
Because of the rules that a transaction is atomic where all actions pass or fail together and the order of the entries doesn't matter, there is a particular order in which to process the actions:
- Process any DELETE interactions
- Process any POST interactions
- Process any PUT or PATCH interactions
- Process any GET or HEAD interactions
- Resolve any conditional references
If any resource identities (including resolved identities from conditional update/delete) overlap in steps 1-3, then the transaction SHALL fail.
nicola (RIO/SS) (Mar 19 2019 at 21:03):
Why the order of the entries doesn't matter?
nicola (RIO/SS) (Mar 19 2019 at 21:04):
This is a simplified view of a transaction - in my test case - order does matter.
nicola (RIO/SS) (Mar 19 2019 at 21:05):
In SQL transactions - order matters because next expression can expect previous one.
Eric Haas (Mar 19 2019 at 21:50):
I think at least it should be called out and possibly added element/extension to cap statements
nicola (RIO/SS) (Mar 20 2019 at 08:20):
@James Agnew @Josh Mandel @Christiaan Knaap what is your opinion about this?
James Agnew (Mar 20 2019 at 10:49):
I think the idea behind the specific order that's described by the spec is that it's the order that makes sense for the fairly common use-case of processing data from external non-FHIR sources (e.g. Hl7v2.x messages) by converting data sources into a transaction bundle that represents the appropriate conversion logic.
Using a transaction in order to provide automatic cleanup for unit tests is a neat idea- why not just specify a custom extension for your server though that forces the transaction to roll back at the end?
Christiaan Knaap (Mar 20 2019 at 19:48):
I understand from this thread that you (@nicola (RIO/SS) ) would prefer to have the client put the entries in the transaction in the right order if that matters to him (or is a FHIR client a 'her'?). Is that correct?
nicola (RIO/SS) (Mar 21 2019 at 05:36):
i’m talking about server, to process operations in transaction in original order, which provided in bundle, because sometimes order matters
Jens Villadsen (Mar 21 2019 at 20:16):
@nicola (RIO/SS) so not the actual order in the XML or Json, right (as order is not guaranteed pr. spec at least in XML)? You would like to, regardless of the order of the interactions in the serialized XML or Json, to process it in the order as you have outlined (meaning that you would possibly rearrange the elements received to match your suggestion )?
nicola (RIO/SS) (Mar 22 2019 at 03:42):
@Jens Villadsen can you elaborate on this - as order is not guaranteed pr. spec at least in XML? Entry in bundle is a sequence with guaranteed order both in xml and json?
nicola (RIO/SS) (Mar 22 2019 at 03:53):
@Grahame Grieve can we have an explanatory block in spec about how this rules works and why with examples? Another small problem is that HTTP method is not very robust - because we can do a search by POST and we do not know semantic of other Custom Operations on FHIR server.
Grahame Grieve (Mar 22 2019 at 05:03):
ok catching up with this...
- why does order matter?
- the key is that you must be able to do forward references in the transaction that are successfully resolved
- changing the way transaction works so it's order based has many problems around failing as a group
Grahame Grieve (Mar 22 2019 at 05:04):
I don't really like your use case, btw
Jens Villadsen (Mar 22 2019 at 08:27):
@nicola (RIO/SS) I forgot all about sequence :grinning: :gun:
nicola (RIO/SS) (Mar 22 2019 at 18:34):
@Grahame Grieve forward reference resolution probably should be implemented in different way, because resources can mutually refer each other
nicola (RIO/SS) (Mar 22 2019 at 18:37):
can you tell more about many problems as a group?
nicola (RIO/SS) (Mar 22 2019 at 18:39):
Why you do not like my example - it’s a good way to test server without side effects
Grahame Grieve (Mar 22 2019 at 21:17):
because server needs to audit the operation, and there's always side effects. I guess I don't like the idea because for me, most operations operate on structures outside the acid bounds of the transaction
Grahame Grieve (Mar 22 2019 at 21:18):
resources can mutually refer each other
that's why transaction is how it is. Not sure what other way would be better.
Grahame Grieve (Mar 22 2019 at 21:19):
and I don't remember all the details about the discussion around transactions. @Ewout Kramer might remember better than I
Ivan Dubrov (Mar 24 2020 at 07:13):
Specified ordering becomes very problematic when extended operations are taken into account. We are considering adding our own extension on a bundle to use client-specified ordering for running transaction bundles.
For example, one of our operations sometimes we need to run before PUT and sometimes after.
Last updated: Apr 12 2022 at 19:14 UTC
