And that we then further override transact-db! to really just wrap a go block and to tree walk the entire body, replacing every (sut/get ...) with (async/<! (sut/get ...)).
PROBLEM: I was thinking that transact-db would also set the bindings, but now that I think about it that is problematic as async is run in (conceptually) a thread pool. Bindings don't necessarily "survive" park events, etc.
SOLUTION: Ok, so I guess I need to make :transaction a key in the third argument we are talking about passing to all the functions (get, set!, add!, and update!). Not only will it asyng/<! all the get but will also merge in the third {:transaction<TRX_OBJ} argument to all of them. I think we are also going to need a :transaction-reads and :transaction-writes passed to each function so that the closing function can know which transactions it has not actually written to the server and write them itself.
POSSIBILITY: Maybe there is a way to query the transaction itself so that we don't need to keep track of reads and writes ourselves.
I am looking at the code that you have written for doing transactions. It currently looks like the following:
I am suggesting that it be moved to the following form.
And that we then further override
transact-db!
to really just wrap a go block and to tree walk the entire body, replacing every(sut/get ...)
with(async/<! (sut/get ...))
.PROBLEM: I was thinking that
transact-db
would also set the bindings, but now that I think about it that is problematic as async is run in (conceptually) a thread pool. Bindings don't necessarily "survive" park events, etc.SOLUTION: Ok, so I guess I need to make
:transaction
a key in the third argument we are talking about passing to all the functions (get
,set!
,add!
, andupdate!
). Not only will itasyng/<!
all theget
but will also merge in the third{
:transaction<TRX_OBJ}
argument to all of them. I think we are also going to need a:transaction-reads
and:transaction-writes
passed to each function so that the closing function can know which transactions it has not actually written to the server and write them itself.POSSIBILITY: Maybe there is a way to query the transaction itself so that we don't need to keep track of reads and writes ourselves.