Hey all, is this a bug?
Edit: AH sorry I realized it works with the latest version of next.jdbc com.github.seancorfield/next.jdbc {:mvn/version "1.3.1048"}
;; latest xtdb docker instance is running with default options
(clojure.repl.deps/add-libs
'{com.xtdb/xtdb-api {:mvn/version "2.0.0"}
com.xtdb/xtdb-core {:mvn/version "2.0.0"}
com.github.seancorfield/next.jdbc {:mvn/version "1.3.955"}})
;;(I also tried this with regular deps.edn deps with the same results)
(require '[xtdb.node :as xtn]
'[xtdb.api :as xt])
(xt/client {})
ExceptionInfo Unknown dbtype: xtdb, and :classname not provided. {:dbtype "xtdb", :dbname "xtdb"}
next.jdbc.connection/spec->url+etc (connection.clj:200)
next.jdbc.connection/spec->url+etc (connection.clj:140)
next.jdbc.connection/eval74115/fn--74116 (connection.clj:473)
next.jdbc.protocols/eval73829/fn--73830/G--73820--73835 (protocols.clj:14)
(def C (xt/client {:dbtype "postgres"})) ;; this works
:dtype "xtdb" support was added in 1.3.967 (2024-12-02).
@seancorfield I'm doing a simple :insert-into into XTDB2 with multiple records and getting a PG error: "No hstore extension installed." I am assuming I'm missing something in my config or requires clause. What should I look for? (Keep in mind I'm porting from PG to XTDB using Clojure Stack Lite.)
this is because the standard PG driver doesn't know (by default) how to send maps over the wire are you using the XTDB JDBC driver?
:dbtype "xtdb" and a recent version of next.jdbc (1.3.1048 is the latest).
(and com.xtdb/xtdb-api {:mvn/version "2.0.0"})
So i figured that much out, but after adding xtdb jdbc driver for 2.0.0, I got a JVM error that xtdb was compiled with a newer version of JVM, so I fixed that, pointing to the right java home. Now I have a different problem: on startup I'm getting an execution NoSuchMethod error for JettyWebSocketServletContainerInitializer/initialize and so the server shuts down after starting up.
that one sounds like a Jetty version mismatch π
I got pretty far on the pg driver before realizing I forgot to add xtdb lol.
Yes, so how to fix that?
well, kinda cool that it mostly Just Worksβ’ with the PG one π
yeah!
usual Maven dependency resolution dance, I'm afraid π¬
Can you link me to "Clojure Stack Lite"? I've no idea what that is...
if you're using deps, try clj -Stree and see if you can spot multiple versions of Jetty being pulled in
then explicitly specify a version that works in your deps.edn
I love Clojure the language for its commitment to eliminating incidental complexity, but the :#&$&*#@! JVM tooling , on the other hand....π€―
yeah... on it.
right when I'm "in the flow" on the domain problem, too.
we're discussing removing the XT HTTP server next week - as far as we know nobody uses it now that PG is the primary API
the only thing jetty related in deps.edn (inherited from clojure stack lite) is ring/ring-jetty-adapter {:mvn/version "1.14.2"}
Found CSL... sheesh, that's a lot of libraries in the mix...
there's starting to be too many of these batteries included frameworks for Clojure, and they're all pretty bloated. https://xkcd.com/927/ π
There's an irony that this is the "lite" one... π
No, no irony, I think it's outright sarcasm. lol.
@seancorfield looks like i have the right next.jdbc version. What do you mean by "type :dbtype "xtdb" - where should I type that? Maybe cuz I'm in a hurry it's not clicking for me.
@jarohen - OK removeing xtdb-core fixed the Jetty problem so yea, maybe take the webserver out in the next release π
Because I do want to use xtdb-core to run in process for tests.
OK, I'm back to my original problem:
No hstore extension installed
I have added xtdb.jdbc.next :as xt-jdbc in the namespace where the db query is being executed. Do you mean add :dbtype "xtdb" to the sql-params?
Ugh! Looks like CSL is using hikari-cp instead of next.jdbc's built-in HikariCP support. I've no idea how it sets up connection pools that way.
sigh
Normally -- when not using a complicated framework! -- you specify a "db-spec" map for your database, and specify the :dbtype key so next.jdbc knows which driver to load.
ok so my connection string is probablly the issue
It seems to me that everyone who creates a "framework" style template really goes overboard on the basic complexity π
Yes, and so much boilerplate has to be removed for what should be orthogonal design choices.
Like, one of the things that annoys me here is using as-unqualified-kebab-maps instead of of using the defaults so you get behavior that doesn't match the docs off the bat.
yeah I noticed some kabob mismatch stuff
I mean, with XTDB you won't get table name qualifiers by default so the unqualified part won't matter for you but hardcoding the builder into the template like that is a bad idea.
around table names IIRC
ok well ... let me test that making the driver xtdb instead of postgresql in the connection string works fine then we'll come back to the sql params
lol yeah - I inserted into :user-type and after that could not find the table "user_type" but rather had to look for "user-type" with quotes in psql.
But the good news is, inserting the map had no difficulty once I added xtdb.api, the xtdb.jdbc.next namespace, and changed connection string to use xtdb instead of postresql.
So now I need to look into using a sane option for :builder-fn instead of jdbc-rs/as-unqualified-kebab-maps.
Though, tbf, the query on the clojure side worked:
(db/exec! (current-db) {:select [:*] :from [:user-type]})
[...results ...]The only issue is it gave the table name "user-type" instead of what a pg dev might expect, "user_type". Not sure it matters but should be noted if people connect to the DB from a standard pg tool wanting to query it.
I think it's OK for now but @seancorfield if you have more advice regarding the :builder-fn option I'm all ears.
Just let it use the default.