This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-02-23
Channels
- # announcements (18)
- # beginners (26)
- # calva (12)
- # cider (43)
- # cljdoc (4)
- # clojure (38)
- # clojure-europe (11)
- # clojure-nl (1)
- # clojure-norway (12)
- # clojure-sweden (2)
- # clojure-uk (4)
- # cursive (17)
- # data-science (4)
- # datalevin (2)
- # datomic (3)
- # emacs (10)
- # ghostwheel (4)
- # graphql (11)
- # honeysql (1)
- # hyperfiddle (7)
- # introduce-yourself (1)
- # malli (23)
- # nrepl (11)
- # overtone (1)
- # pathom (9)
- # pedestal (2)
- # polylith (1)
- # portal (3)
- # reitit (1)
- # shadow-cljs (12)
- # timbre (4)
- # vim (2)
- # xtdb (4)
@taylor.jeremydavid I’ve been playing around a bit with xtdb v2 and I’m really confused as to the state of datalog queries. It seems like they’re gone and are being replaced by XTQL?
Hi @U0545PBND that's essentially correct, yes. We decided to forego the {:find [...] :where [...]
syntax in favour of something more amenable to working with multiple relations (n-ary tables) and relational composition more generally. Instead, the unify
operator in XTQL is a Datalog-like unification scope where joins can be expressed succinctly. Is there an aspect of the original syntax that you feel is missing?
Ah, yes the v2 query engine works quite differently (tables, full bitemp, 3VL, no clojure.core/*
etc.) so the query semantics were always destined to be incompatible. In the end we decided it would be preferable to offer a query language that was more sympathetic (and therefore simpler) to the new capabilities