This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-27
Channels
- # announcements (7)
- # aws (1)
- # beginners (42)
- # calva (65)
- # clj-kondo (5)
- # cljs-dev (11)
- # clojure (69)
- # clojure-australia (7)
- # clojure-dev (4)
- # clojure-europe (9)
- # clojure-gamedev (2)
- # clojurescript (2)
- # conjure (4)
- # cursive (1)
- # data-science (1)
- # datomic (8)
- # events (1)
- # fulcro (35)
- # graalvm-mobile (40)
- # introduce-yourself (1)
- # lsp (26)
- # malli (14)
- # mathematics (2)
- # missionary (5)
- # nextjournal (4)
- # off-topic (4)
- # polylith (10)
- # shadow-cljs (5)
- # test-doc-blocks (1)
- # tools-build (24)
- # tools-deps (1)
- # xtdb (12)
The documentation of the Custom transaction functions lists: • atomic transformation functions in transactions • integrity checks and constraints • spec-based validators • and much more - your imagination is the limit! I'm i correct in understanding that only the first item listed "atomic transformation functions in transactions" is actually unique to transactions? That is, you could do spec based validations on data before it's transacted but with a transaction function you can do during the transaction.
I couldn't find anything in the docs about it. I assume the just add a spec validation in the middle of the transaction function. The same way you could add any valid clojure code.
What is the minimal iam role for connecting and reading datomic? Is there such a role by default? Ah now I see there is an admin and a readonly policy
@drewverlee As an example - you can verify a cardinality 1 relationship with a schema, but i don’t think you can validate a foreign key relationship without transaction functions
That makes sense.
You can't reliably validate anything that has a multi-datom dependency without atomicity. If you're validating it while something else is modifying it then your final transaction will result in potentially invalid data. You can use CAS to mitigate that as long as you CAS on the stuff you read as well as the stuff you write. I have a system where there is a central owner entity for each account. I find transactor functions hurt throughput too much when they contain a lot of validation, so I instead do an optimistic concurrency control where I CAS on a counter (no history) on that entity to increase it by one from what I read before starting validation. I'm essentially treating that counter like an account-level db lock. That ensures only one tx can run per account at a time even though most of the work is done outside the tx.
Very interesting, i'll have to give that some thought.