This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-05-05
Channels
- # aleph (10)
- # announcements (2)
- # babashka (83)
- # beginners (41)
- # biff (2)
- # calva (6)
- # cider (7)
- # clerk (3)
- # clj-kondo (7)
- # clojure (89)
- # clojure-berlin (1)
- # clojure-brasil (4)
- # clojure-dev (15)
- # clojure-europe (16)
- # clojure-nl (1)
- # clojure-norway (54)
- # clojure-spec (1)
- # clojure-uk (4)
- # clojurescript (2)
- # conjure (3)
- # datomic (7)
- # emacs (4)
- # events (1)
- # figwheel-main (1)
- # graalvm (5)
- # gratitude (2)
- # honeysql (14)
- # hyperfiddle (86)
- # introduce-yourself (1)
- # joyride (9)
- # lsp (179)
- # malli (29)
- # music (1)
- # nyc (14)
- # off-topic (6)
- # polylith (16)
- # rdf (8)
- # releases (2)
- # rum (1)
- # shadow-cljs (26)
- # specter (2)
- # sql (4)
- # uncomplicate (2)
- # xtdb (16)
I'm trying to get a datomic pro transactor running on Windows, just for local dev development. When I call
bin/transactor.cmd c:/path/to/sample-dev-config.properties
I get
The input line is too long.
The syntax of the command is incorrect.
When I turn echo on in the cmd scripts, the last command before the error is:
call bin\cpbuild.cmd .\lib\aws-java-sdk-lambda-1.12.358.jar
Any tips?Ah I see this was reported here: https://ask.datomic.com/index.php/662/can-i-run-recent-versions-of-datomic-in-windows
It seems common to use Datomic with complementary databases (data warehouses/lakes, full-text search, etc). These federated systems leverage Datomic’s characteristics as the “system of record” but pour some data into other databases. To ensure the integrity of the whole, I’m aware of two seams used to coordinate: transaction functions and log scanning (roughly speaking). Transaction functions are attractive in that you can be confident in the coordination by focusing on events. And since the transctor is a choke point, there is no requirement for idempotency. But the initial satisfaction erodes quickly when you have to address any kind of condition that causes things to go out of sync (including initial conditions!). And the impact to performance in the single-writer system can be unacceptable. Log scanning seems to be a better solution. It’s really efficient to scan the log for transactions that meet certain criteria. In fact, with some generalization you can turn log scanning into a poor-man’s event sourcing (here’s an example: https://vvvvalvalval.github.io/posts/2018-11-12-datomic-event-sourcing-without-the-hassle.html#how_datomic_does_it). WIth multiple log scanners (for resiliency) idempotency needs to be considered, but otherwise this seems to be the preferred solution. Musing, since Datomic peers (and maybe Ions ?) are already “subscribed” to the stream of transactions, can Datomic offer an async API delivering some derivative of the transaction stream? Of course performance could be challenging at high volumes, but the programming model seems ideal. A core.async channel transduced with a filter to the trxs of interest would be a powerful concept that seems to play to Datomic’s strengths. Otherwise I’m stuck polling the log.
You are looking for d/tx-report-queue https://docs.datomic.com/pro/clojure/index.html#datomic.api/tx-report-queue
But honestly polling is fine and easier to synchronize with an external “tx cursor” position state for the consumer. This just decreases latency