Hey #xtdb - can I get a show of hands (or DM, if you don't want to publicly admit it!) of folks who'd want to be involved in/informed of any upcoming changes to XTQL? specifically, in this round, we're looking at what's involved in getting XTQL inlinable into SQL queries - both as a standalone query, but also (for bonus points) as a SQL subquery/sub-table reason we're looking to combine the two is largely to open XTQL up to normal Postgres tooling - so imagine a world where you're able to query XTQL through Metabase or similar π but also, behind the scenes, because the APIs (xtdb.api and pgwire) are starting to diverge a little, which is a little concerning to us - we're at risk of needing to double-implement new functionality in the pgwire and Clojure APIs π
e.g. basic case - sending your XTQL queries through next.jdbc:
(require '[next.jdbc :as jdbc]
'[xtdb.next.jdbc :as xt-jdbc])
(jdbc/execute! xt-node [(xt-jdbc/xtql '(-> (from ...) ...))])
;; before, for comparison
(require '[xtdb.api :as xt])
(xt/q xt-node '(-> (from ...) ...))(cc @taylor.jeremydavid)
xt-jdbc/xtql would just be a helper - expands to the following XT SQL extension (but you're still writing data-oriented queries, so no injection attacks)
XTQL $$ (-> (from ...) ...) $$
('$$' being string delimiters in Postgres to avoid needing to escape quotes)then, because everything's 'just a relation', you can inline this within larger SQL queries:
FROM XTQL $$ (-> (from ...) (...)) $$
WHERE ...
SELECT ...
ORDER BY ...> but also, behind the scenes, because the APIs (xtdb.api and pgwire) are starting to diverge a little on this one, we'd likely either move to having the Clojure API calling next.jdbc on your behalf - or, if it's such a small layer that it's not worth a layer, we may look to deprecate it entirely (maintaining the ability to create small throwaway XT nodes for unit tests, of course, because that's awesome)
From a HoneySQL / language spec / parsing p.o.v., I'm very interested in this.
@seancorfield in HoneySQL, I might consider adding something like [:xtql '(-> (from ...) ...)] , implementation being (fn [xtql] (format "XTQL $$ %s $$" (pr-str xtql)))?
otherwise, it should be opaque within the SQL string
Interesting suggestion...
obv you're way better placed to decide what'd be idiomatic HoneySQL π example above just to show that it's a simple transformation
I created a GH issue about it. I'll see what else comes up in this thread.
@dpsutton yep, we've implemented just about enough of Postgres that it seems to handle XT pretty well π tempted to try adding some valid-time/system-time smarts to Metabase given it's Clojure, some form of timeline sliders or history UI or something. one for a hack day π
although tbh its graphing is already pretty good - might 'just' be the syntactic awareness of the SQL:2011 temporal additions
querying XTQL through Metabase π (in flight)
XTQL can also be a subquery in a bigger SQL query (because everything's just relations)
Woah. This is really cool
Is this using the Postgres driver?
how'd this appear here...? π» π
I used Slack to create an issue from a message in this channel, so GH helpfully told the channel that I'd done it (and it also posted it in #honeysql)
aaah, gotcha
neat π
The Slack/GitHub integration can be a bit... enthusiastic... in its communication.
I've never created issues on GH from Slack
I use it a lot, since folks here often chat about good ideas for the various libraries I maintain π
Hello, whats the latest on XTDB 2.x for handling geospatial data?
Hey @wes there's no special support just yet in either the standard library or indexes. What kind of functionality do you need? Simple proximity? Polygon intersections?