Fork me on GitHub
#xtdb
<
2019-12-11
>
djtango12:12:11

Hi what is a good choice for :crux.node/kv-store if I want to run a JDBC postgres setup locally? I can't seem to find the possible options for :crux.node/kv-store in the documentation

Ivan Fedorov16:12:19

I would check examples directory, but I’m not sure

refset20:12:29

@U0HJD63RN hey! Sorry for the late response on this - the answer is RocksDB is a sensible default, and you'll want to use this alongside the JDBC topology options (https://opencrux.com/docs#config-jdbc)

:crux.node/kv-store "crux.kv.rocksdb/kv"
:crux.kv/db-dir "data/db-dir-1"

refset20:12:48

did you get it working already?

djtango21:12:45

Ah thanks @U899JBRPF Didn't realize that you JDBC driver was only a replacement for the kafka commit log?

djtango21:12:57

Ie there isn't a jdbc kv store implementation

djtango21:12:10

Not yet but got tied up this week

refset21:12:47

Ahh, yes that's how crux-jdbc works today. It's plausible to write a KV backend for SQLite but RocksDB/LMDB will be faster. The main requirement for the KV indexes is that they are local to the query engine, so it's not feasible to use a "remote" KV store powered by e.g. a Postgres cluster

plexus15:12:53

when calling crux/db immediately after crux/submit-tx, is it guaranteed that I see the changes that were just transacted?

plexus15:12:55

ok, thanks!

Ivan Fedorov16:12:26

Thanks for asking, I’ll extend the the docstring, when I’ll be around or perhaps @U899JBRPF may get there first

✔️ 4
plexus16:12:09

Is there a way to use the :crux.tx/tx-time that submit-tx returns to sync up to that point? I'm trying this

(defn submit-tx [crux tx-ops]
  (let [tx-time (:crux.tx/tx-time (doto (crux/submit-tx crux tx-ops) prn))]
    (crux/sync crux tx-time 1000)
    nil))
but this returns
Unhandled java.lang.ClassCastException
java.util.Date cannot be cast to java.time.Duration

plexus16:12:40

nvm it's the timeout that has to be an instance of Duration duckie

👍 4