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.Updates are async. I think you need to wait for that second submit to complete?
No, that's not it.
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?
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
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.