Just want to check, is this a correct implementation of a "blocking-submit" that just blocks until the db contains the submitted entities?

(defn blocking-submit [node tx]
  (let [result (crux/submit-tx node tx)]
    (crux/sync node (:crux.tx/tx-time result) (Duration/parse "pt1s"))
    result))

Ok here is the problem I'm hitting

(defn put-and-return-id [node]
  (let [id (java.util.UUID/randomUUID)
        tx [:crux.tx/put {:crux.db/id id}]]
    (blocking-submit node [tx])
    id))

(crux/entity (crux/db db) (put-and-return-id db)) ;;returns nil

(let [id (put-and-return-id db)] ;;correctly returns entity
  (crux/entity (crux/db db) id))

The strangest thing is this doesn't work either:

(crux/entity (crux/db db)
             (do (let [x (put-and-return-id db)]
                   (Thread/sleep 1000)
                   (prn x)
                   x))) ;;=> nil

OH nevermind I get it now

the (crux/db db) call is evaluated before the entity is put in the DB, so it's not in the database at that point.

@jjttjj Ahh, yeah I think this whole area remains a gap in the docs / examples / tutorial - sorry. We should probably figure out and document some backoff & retry patterns too. Have you seen the sync function?

Yes, my first message above uses sync to wrap submit-tx

but this was kinda a different issue it turns out

Ohh yeah, my bad 🙂

No worries 🙂 just glad I eventually realized this haha

in trying to switch from rocks-db to jdbc I'm getting this error

Execution error (FileNotFoundException) at  (io.clj:149).
Could not locate crux/kv/rocksdb__init.class, crux/kv/rocksdb.clj or crux/kv/rocksdb.cljc on classpath.

I've commented out the rocks-db dependency and even the call to (crux/start-standalone-node crux-options) and still get this error with a fresh repl

oh looks like kafka and jdbc are only for the tx-log? I assumed postgres could be used as a kv-store via hstore

https://www.postgresql.org/docs/9.0/hstore.html

that would be optimal! the way I was planning to use this is with a deployed postgres cluster I have for young side projects. if this works I could use one cluster with many relational tables and as targets for crux nodes

so, am I right that I couldn't get away with one DB (postgres) at the moment because an additional kv-store is required?

Hi @denik currently that's the case, it should be straight enough to have postgresql as a kv store

If the k/v store is over the wire to the node, then queries would be slower. This is because the query engine is chatty with the k/v store that is currently local.

@jonpither thanks for the quick response. Yes, it would be over the wire but in the same data-center. Will the k/v store be rebuilt from the tx-log? I don't mind using rocks-db as a kv-store, just want to avoid buying storage volumes for every deployment.

Yes the k v store is always rebuilt from the log.