Refactor _TransactionQueueManager to delineate transaction preparation and completion.#19670
Refactor _TransactionQueueManager to delineate transaction preparation and completion.#19670reivilibre wants to merge 2 commits intodevelopfrom
_TransactionQueueManager to delineate transaction preparation and completion.#19670Conversation
| if not self._pdus and not pending_edus: | ||
| return [], [] |
There was a problem hiding this comment.
This is the only part that actually got removed, because it didn't seem worth having an early return to save 1 if statement.
| @@ -0,0 +1 @@ | |||
| Refactor `_TransactionQueueManager` to delineate transaction preparation and completion. No newline at end of file | |||
There was a problem hiding this comment.
I think this is an OK change, though I'm a bit confused why moving the variables into a separate class is simpler? As it is I'm not sure this really simplifies things, beyond the extra comments?
There was a problem hiding this comment.
I mean you're not wrong, it's not a wholly important change.
If I had to put words to it, I guess I have a preference for passing immutable structs around rather than having fields in some 'unset' state on self and mutating them. (Another illustration is: Option<struct> vs struct with Option<> on every field.)
If you don't have this preference it may make less sense.
For sticky events I intend to add a new way of preparing transactions and some new code to run on completion; I felt that it would be messy to just add to the pile of unset things
3 participants
A small commit that splits up
_TransactionQueueManagerto pass through its information in a new struct,making the data flow easier to see.
The grand plan is that this will make it easier to have an alternative mode of transaction preparation,
for sticky event backlogs.