This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (22)
- # architecture (6)
- # beginners (76)
- # cider (44)
- # clara (6)
- # clj-kondo (34)
- # cljdoc (4)
- # cljs-dev (8)
- # clojure (162)
- # clojure-brasil (4)
- # clojure-dev (32)
- # clojure-europe (3)
- # clojure-italy (16)
- # clojure-japan (4)
- # clojure-nl (3)
- # clojure-poland (1)
- # clojure-spec (25)
- # clojure-uk (45)
- # clojuredesign-podcast (5)
- # clojurescript (91)
- # clojutre (3)
- # core-async (19)
- # core-logic (8)
- # cursive (60)
- # data-science (3)
- # datomic (7)
- # defnpodcast (2)
- # duct (5)
- # emacs (7)
- # fulcro (1)
- # graalvm (9)
- # graphql (1)
- # jackdaw (12)
- # jobs (1)
- # jobs-discuss (1)
- # kaocha (3)
- # leiningen (3)
- # luminus (2)
- # off-topic (44)
- # onyx (17)
- # pathom (6)
- # planck (15)
- # re-frame (1)
- # reagent (13)
- # rum (2)
- # shadow-cljs (43)
- # spacemacs (3)
- # sql (43)
- # tools-deps (3)
- # vim (43)
- # xtdb (13)
@jonpither @dominicm Thank you for the embedded PG information --
next.jdbc now includes automated tests against (embedded) PostgreSQL on master! So of course now the test suite is full of conditionals since that's the first DB in the automated suite that returns lowercase table/column names 🙂
I'm having some problems getting HikariCP to work with
next.jdbc, I'm running on Ubuntu and connecting to MS SQL
(jdbc/execute! (jdbc/get-datasource db-spec) [query]) works fine using both
When I run
(with-open [^HikariDataSource ds (connection/->pool HikariDataSource db-spec)] (jdbc/execute! ds [query]))
jtds, it throws a SQLException
I/O Error: GSS Failed: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt).
mssql, I get
Login failed for user
Because the options to Hikari do not use the standard
:user/`:password` options like regular datasources.
You have to provide
:mixedCase keywords that match Hikari's world view. Very annoying but a fact of life, unfortunately.
:username instead of
:user. Based on the docs, I think that should work.
I think that might be true of c3p0 as well...
...nope, that uses
.setUser()). Ain't that great?
These are confusing docs! They have
props.setProperty("dataSource.user", "test"); right below
Yep, that's all I had to do - thanks!
I'll update the docs to add a warning about that...
Yeah, that would be great! I should have it working with Integrant right away, do you think that would be worth adding to the docs underneath the Component section? Or maybe move it into a separate HikariCP document.
It also doesn't seem to work with
mssql is fine though.
Interesting. But the
jtds db-spec works fine without HikariCP in the mix?
The Getting Started page (on master) now says:
Note: HikariCP expects :username instead of :user when supplying authentication credentials. c3p0 expects :user, just like in a regular db-spec hash map.
Yeah - it's not listed at https://github.com/brettwooldridge/HikariCP#popular-datasource-class-names as supported and I found a couple posts an slack overflow that made it seem like it
jtds didn't really work with it.
That looks very helpful 🙂
If I put both
:username in my db-spec it doesn't cause any problems with either
jdbc/get-datasource or HikariCP, though I haven't tested with C3PO.
I'm going to try it with C3PO now, and see if any of these things will break it, too.
I appreciate all this testing and feedback! Thank you!
I appreciate having fun new libraries to play with 🙂
Here are some REPL tests with results, in case you want to experiment at all
I totally expect HikariCP to fail when you dissoc
:username, and I totally expect the other cases to fail when you dissoc
So the HikariCP/jtds combo is the interesting oddity. Do you have more details about what exactly fails?
Not really - I kind of wondered if I was doing something wrong there, which is partly why I thought I would just hit every option I could think of. I found https://stackoverflow.com/questions/42247864/configure-hikaricp-in-spring-boot-with-jtds/50891863 which at least looks like the same error message - not sure if it's actually relevant, though.
Ah, so specify
:connectionTestQuery "SELECT 1" and it should go away.
LMK if that works and I'll add another note to Getting Started 🙂
I’ll give it a try tomorrow and see! Thanks!
Yep, adding that to the db-spec fixes the 2 places that were throwing AbstractMethodErrors. I think that means everything works as expected now.
Brilliant! I'll update the Getting Started docs -- thank you!
https://github.com/seancorfield/next-jdbc/blob/master/doc/getting-started.md#connection-pooling (that'll get into the http://cljdoc.org version whenever I release 1.0.5).
The only other thing that I think could cause problems -
jtds didn't work for me with
:username only (though
mssql did), so if someone is trying to get up and running with
jtds and HikariCP I can totally see them running into problems doing non-pooled queries if they don't include
:user as well.
Really? That's a bit weird. HikariCP ignores
:user as far as I know...
Oh, I see what you mean. Right
:username is only needed for HikariCP. It is not needed otherwise.
:user is the right thing to use.
I'm a bit surprised that
mssql works with
:username instead of
:user -- that's non-standard (well, in the world of "standard" here).
Yeah - I think the only issue will be if people are thinking it's a replacement instead of an additive thing, not sure if it's necessary to clarify that in the docs or not. I bet the
mssql team threw it in because they got sick of dealing with support questions from HikariCP developers.
I haven't supported anything like this, so I don't know if it would be worth special casing any of this in
spec->url+etc - I have no idea how you are still relatively sane after dealing with all the little inconsistencies of different SQL stuff for this long. 🙂
I can't imagine people using both pooled and non-pooled connections in the same app, to be honest.
However, I've updated the wording in that caveat -- see if it is clearer now?
Yeah, that wording looks great to me.