I’ve just updated seancorfield/next.jdbc.xt: Experimental extension of next.jdbc to work with XTDB 2.0 (snapshots) (github.com) to work with the latest 2.0 snapshot, and the README now includes examples for both the in-process XTDB node and the HTTP client.
I’ll be keeping this updated more often as I’m actively starting to work with XTDB 2.0!
seancorfield/honeysql: Turn Clojure data structures into SQL (github.com) has had support for temporal queries for several months now so you can use that to construct SQL+params vectors to use with next.jdbc when working with XTDB.
3 Likes
This looks great @seancorfield, thank you!
As a follow-up, I have created a version of my usermanager-example app that uses XTDB 2: seancorfield/usermanager-example at xtdb (github.com) – and still uses next.jdbc via the next.jdbc.xt bridge.
The tests use an in-process XTDB node. The application uses a standalone XTDB instance, on localhost:3000 by default. The README has (brief) instructions on how to use Docker to run XTDB 2 early access locally for this.
Note: In the original app with SQLite (and H2 in-memory for tests), next.jdbc produces table-qualified keys when querying via JDBC. The next.jdbc.xt bridge doesn’t use JDBC: it implements the next.jdbc API by calling into xtdb.api directly, so there are no result sets and no metadata for queries – you get back whatever XTDB’s API returns. Rather than try to overlay qualified keys on the results in usermanager-example, I felt it would be easier to follow the code if I just left everything unqualified. I’m still ruminating on how much of the result set machinery I want to try to replicate in next.jdbc.xt (given that a column key like :foo/bar is perfectly valid in XTQL and ends up as foo$bar in SQL).
2 Likes