Welcome! Please see the About page for a little more info on how this works.

0 votes
in java.jdbc by

Hi there

In java.jdbc, when using a raw connection uri, properties cannot be passed in and have to be part of the uri, except for username and password which can be taken from the db-spec, as there is a DriverManager constructor that takes username and password specifically. DriverManager does, however, provide another constructor in which any properties can be provided, including username and password. Would it be possible to use that constructor instead? Here is what the change would look like: https://github.com/dmcgillen/java.jdbc/commit/95edd36997320d8dc6882ea371d88c901e49f465#diff-3a9a3475f16407a50d922fad53957b01L293.

For context, this has come up for me since I've been using an AWS Secrets Manager JDBC wrapper, which takes the secret id as a connection uri. I'd still like to provide other JDBC properties, but they are expected to be provided as in the change above, and it seems like a good idea to support properties being passed in this way.

Let me know if I should have created a JIRA rather than posting here and I can do so (if this change is a good idea, of course).


1 Answer

+1 vote
selected by
Best answer

Per the clojure.java.jdbc readme: This project is "Stable" (no longer "Active"). It has effectively been superseded by seancorfield/next.jdbc.

next.jdbc takes a different approach to making data sources and connections so I think you'll run into a similar problem, but I'd be open to doing something about it in that project. Feel free to create a GitHub issue there for discussion.


I think allowing a db-spec that contains :jdbcUrl (which matches the ->pool usage) would provide a solution to this.
seancorfield/next.jdbc 1.0.8 is available on Clojars with this new feature added.
That's a shame, looks like I just missed the boat! Thanks for adding it to next.jdbc so quickly, good to know it'll be supported there when we start using it.
For anyone else's benefit, just use datasources, which clojure.java.jdbc supports. We already were where connection pools are used, but we have some apps that don't use a pool, but they can still work using a datasource.

For those apps, we're using next.jdbc's get-datasource function to create the datasource (which contains the above changes so we can use a jdbc uri with properties, thanks!), but using that datasource with clojure.java.jdbc, until such a time comes when we can migrate.
Glad that's working out for you Donovan! We're also a mixed c.j.j. / next.jdbc shop, and we have c3p0 connection pools for all (legacy) code so we're just passing (:datasource pooled-db) into the next.jdbc functions.