This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-18
Channels
- # announcements (5)
- # aws (14)
- # babashka (5)
- # beginners (39)
- # brompton (9)
- # chlorine-clover (10)
- # cider (2)
- # clj-kondo (107)
- # cljfx (2)
- # cljsrn (7)
- # clojure (40)
- # clojure-australia (2)
- # clojure-conj (5)
- # clojure-europe (11)
- # clojure-japan (2)
- # clojure-nl (3)
- # clojure-spec (1)
- # clojure-uk (6)
- # clojurescript (8)
- # cursive (20)
- # datahike (6)
- # degree9 (2)
- # deps-new (2)
- # development-containers (11)
- # fulcro (26)
- # jobs (1)
- # joker (1)
- # kaocha (1)
- # lambdaisland (1)
- # malli (6)
- # membrane (1)
- # nbb (1)
- # news-and-articles (2)
- # off-topic (3)
- # pedestal (23)
- # re-frame (19)
- # reagent (6)
- # sci (110)
- # shadow-cljs (7)
- # tools-deps (9)
- # xtdb (20)
what is the "cost" of updating a document? I'm thinking should refs be modeled in such a way that you minimize how many documents you need to update in a tx (eg, a child referring to its parent instead of parent having a vector of child ids)
I think you should always prefer back references unless you need ordering and can't model that ordering outside of crux
^ preferring back references is usually good advice. The main cost of generating many updates to the same document is the storage cost due to full duplication within the document store (which doesn't (currently) benefit from any possible structural sharing - unlike the local indexes), and also there is also some performance cost when processing larger documents with massive numbers of forward references
another new comer question: in a clustered environment, how do the nodes coordinate who is doing writes? is that affected by what storage for tx log you are using
all nodes can submit transaction writes as equal citizens, but the transactional (ACID!) ordering of the writes is governed by the single-writer tx-log backend (which is a single-writer regardlesss of which tx-log backend storage you choose)
also "submit" to whom, who does the storing and index updating? the node doing the submit
any form of locking happens behind the scenes in the implementation. submit-tx
on the db/TxLog
protocol simply expects a Delay which is deref'd (blocking) as part of the user-facing crux.api/submit-tx
API
each node will put
documents to the doc store and submit it's own transactions to the tx-log as part of crux.api/submit-tx
later, irrespective of which node did the submitting, each node will read and locally index the transactions (and pull down the referenced documents from the doc-store for processing)
nvm, those aren't networked servers... so I guess the above still stands, that each node will have their own indexes
sounds right to me 🙂 yep, the index stores are all local to each node, and there's no co-ordination between each node, except via the central TxLog (Kafka or equivalent)
Is it a bug that I am not able to use (instance? java.time.LocalDate ?t)
in a where
clause? I get "Clause refers to unknown variable: java.time.LocalDate...