Jeremy Taylor
Jeremy Taylor
A fairly minimal repro: ```clojure (def node (xt/start-node {})) (xt/submit-tx node [[::xt/put {:xt/id :asdf/asdf :first-name :john}]]) (xt/q (xt/db node) '{:find [e] :in [i] :where [(or-join [e i] (and [e :first-name...
See `clojure.java.jdbc` blog post for insights on how hard/easy this could be: http://corfield.org/blog/2018/12/03/datafy-nav/ Test with https://github.com/Lokeh/punk#jvm Other inspiration: https://github.com/tonsky/datascript/pull/325
Using multiple eviction operations in a single transaction does not currently scale well: 1 eviction "Elapsed time: 43.803538 msecs" 100 evictions "Elapsed time: 301.938175 msecs" 1,000 evictions "Elapsed time: 9686.182016...
Priority 1. tx lag (vs. index-store) Bonus(?) 1. Slowest queries 2. etc.
Currently, the `crux-http-server` HTTP API doesn't offer HTTP users the ability to benefit from `with-tx` (and therefore also users of `crux-http-client`). Part of the challenge is that our HTTP semantics...
All of the existing benchmarks in the nightly runs await the finished indexing step before beginning any queries. A new test would give us better visibility of regressions and improve...
Ideas for requirements (in no particular order): 1. Visualise a 2D vt-tt graph 2. Configurable default time ranges, e.g. 1 day, 1 week 3. The history of one particular entity...
e.g. `:my.ns/2020-02-10_增强亚式` I haven't tried to reproduce this via Java yet, but I did confirm that both Clojure local & remote APIs handled UTF-8 fine. (private) Context: https://juxt-oss.zulipchat.com/#narrow/stream/277787-Tongyu-JUXT/topic/.22No.20matching.20clause.20.22.20error/near/226541041
First-class async APIs could ease the challenges of writing high-performance code around Crux, and expand the reach of Crux to applications built entirely using async execution frameworks: > Asynchronous processing...
Query timeouts currently throw exceptions on the calling thread, but they could also be tracked as events by `crux-metrics` - both number of timeouts and timeout rate.