xtdb

zeitstein 2025-03-04T20:21:58.621049Z

Can somebody explain this one to me?

(def node (xt/start-node {}))

(defn submit [data]
  (->> (mapv #(vector ::xt/put %) data)
       (xt/submit-tx node)))

(comment
  (submit [{:xt/id 0 :num nil}]) ;; this is the culprit
  (submit [{:xt/id 0 :num 0} {:xt/id 1 :num 1.5} {:xt/id 2 :num 2} {:xt/id 3 :num 1.5}])
  (xt/q (xt/db node)
    '{:find [e]
      :where [[e :num v]
              [(clojure.core/> v 1.4)]]})

  ;; Execution error (NullPointerException) at xtdb.query/eval72711$fn$pred-constraint (query.clj:1040).
  ;; clojure.lang.Numbers/ops (Numbers.java:1095)
  ;; clojure.lang.Numbers/gt (Numbers.java:261)
  ;; clojure.core/> (core.clj:1079)
  ;; ...
  )
I wouldn't expect this to occur because a new version of the entity has been transacted.

seancorfield 2025-03-04T21:16:06.388979Z

Updates are async. I think you need to wait for that second submit to complete?

zeitstein 2025-03-04T21:23:34.946069Z

No, that's not it.

refset 2025-03-04T21:42:13.450719Z

Hey @mithrandir03 I have a hunch that it's because :num v is being scanned earlier in the join order, before any temporal resolution is happening (i.e. the old value is getting processed even though it will be filtered out later). Running xtdb.query/query-plan-for and seeing the :vars-in-join-order vector can probably confirm this ordering, that v comes before e Interestingly though I think you're the first person to raise this error, I don't recognise it(!) Has it broken your db/app? Are you blocked?

refset 2025-03-04T21:43:36.006219Z

Workarounds may include using the built-in > instead of clojure.core/> (although I assume you have your reasons for that), and implementing a new version of > which has some defensive nil handling

zeitstein 2025-03-04T21:46:06.330819Z

Hey 🙂 You are right about the join order! Using core fn because of: https://github.com/xtdb/xtdb/issues/1298. Yes, I'll need to play defense anyway so not blocked, thanks.

👍 1
🙏 1