This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-06-08
Channels
- # babashka (9)
- # beginners (43)
- # biff (4)
- # calva (11)
- # cider (6)
- # clerk (1)
- # clj-kondo (4)
- # cljs-dev (6)
- # clojure (82)
- # clojure-berlin (1)
- # clojure-europe (42)
- # clojure-nl (1)
- # clojure-norway (182)
- # clojure-quebec (1)
- # clojure-uk (19)
- # clojurescript (6)
- # datahike (1)
- # emacs (30)
- # fulcro (5)
- # honeysql (6)
- # hyperfiddle (12)
- # lambdaisland (8)
- # malli (11)
- # off-topic (36)
- # pathom (26)
- # pedestal (1)
- # portal (25)
- # practicalli (1)
- # rdf (29)
- # re-frame (17)
- # reitit (1)
- # releases (1)
- # sci (37)
- # shadow-cljs (15)
- # vim (10)
- # xtdb (13)
Question:
• we run xtdb in embedded mode, with rocksdb/postgres stores
• we experimented with running the app with a replication factor of 2 (instead of 1), but ran in some "stale/missing read" problems when serving REST calls, which is logical because the request hitting the second node might arrive before the transaction done in the first node has propagated to the rocksdb indexes on the second one
I was wondering which options are typically considered to mitigate this problem, we were thinking of either:
• use (xt/sync)
in each request handling chain before querying the db? I'm wondering how expensive / idiomatic this approach is?
• run XTDB standalone and have both app nodes talk to XTDB as a service
• others that come to mind?
Thanks for your perspective 🙏
Hey @U052A8RUT 👋
Yep, that's most likely what's happening. Calling xt/sync
before reads wouldn't be the worst thing in the world if you have relatively low write throughput; otherwise (an approach we're using in v2), you could keep track of the latest transaction you've submitted, and ask to await that before running the query
Running XT as a standalone server and connecting through the remote API is also a valid option 🙂
Ok great! xt/sync
sounds doable as we're not that write-heavy. Cheers
Hi, I am using postgres for xtdb and wondering if there is any way to see the content of the entries on SQL clients (e.g. postico). For example as shown in the screenshot below, the v
field only says the content is binary. But it'd be great if I can see content or any part of it there.
Or should I use some other client program?
Hey @U022N1DU7GQ 👋 these are encoded in https://github.com/ptaoussanis/nippy format - if you have a client that'll give you back the binary representation you can fire it via nippy/thaw
to get the object back
@U050V1N74 I see. So I can do it on clojure repl rather than portico or psql, is this correct?
ah, you could use postgres's encode(v, 'base64')
, then it can go straight to nippy's thaw-from-string
When business people, who don't necessarily know clojure, need to analyze data, how do they see the data in xtdb usually?
we only really offer a Datalog query engine in 1.x I'm afraid. we have heard of a few non-Clojure folk learn Datalog rather than the whole of Clojure - understand that's quite an ask though! full SQL support is available in 2.x (currently in very early access) though, for exactly that reason 🙂
https://docs.xtdb.com/extensions/sql/ there is the apache calcite route if you want to connect analytics tools to your xtdb