Details
-
Task
-
Status: Closed
-
Major
-
Resolution: Done
-
None
-
None
-
None
Description
Currently select and update operations stack is structured roughly as follows:
--> filter1 enter ---> filter2 enter ----> ... -----> tx start ------> run operation -----> tx end ----> ... ---> filter2 exit --> filter1 exit
I.e. all filters are outside of the transaction (though I guess a filter can preemptively start a tx on its own). Very often we'd like to invert that as follows:
-> tx start --> filter1 enter ---> filter2 enter ----> ... -----> run operation ----> ... ---> filter2 exit --> filter1 exit -> tx exit
or maybe mix pre- and post-tx filters:
-> filter1 enter --> tx start ---> filter2 enter ----> ... -----> run operation ----> ... ---> filter2 exit --> tx exit -> filter1 exit
So I guess a way to control this behavior is by moving TX code into its own filter, and registering it by default. We will also need a change in DI API to allow callers to control the order of DI list items insertion, so that custom filters can be inserted either before or after a given filter. E.g.:
ListBuilder.add(label, object).after(label1); ListBuilder.add(label, object).before(label2);