(jdbc/execute! (jdbc/get-datasource db-spec) [query]) works fine using both mssql and jtds drivers

When I run

(with-open [^HikariDataSource ds (connection/->pool HikariDataSource db-spec)]
    (jdbc/execute! ds [query]))

with 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.

Try :username instead of :user. Based on the docs, I think that should work.

See https://github.com/brettwooldridge/HikariCP#initialization

I think that might be true of c3p0 as well...

...nope, that uses :user (for .setUser()). Ain't that great?

These are confusing docs! They have props.setProperty("dataSource.user", "test"); right below ds.setUsername("bart");

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 jtds, 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 :user and :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 :user.

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.