Fork me on GitHub

@gdeer81 [org.clojure/java.jdbc "0.7.1"] is available from Maven now, so you can try that connection string out again.


Excellent that's much better, now I guess I should open up an issue on migratus to bump their version of java.jdbc


is it possible to print which query a command like jdbc/insert! is generating?


@plins Not at present, no. I've been looking at ways to generically obtain the actual SQL statement from the PreparedStatement underneath but that doesn't seem to be possible. For query there's :explain? and :explain-fn which are mostly generic (but don't always show the actual SQL, just the plan used).


Feel free to create an issue on JIRA for me to look at alternative ways of providing access to the actual SQL statement used.


IIRC, there is a generic jdbc query logging class available


I've also been trying to play with Sayid to see if I can replace blackwater (sql benchmarking) and my hand rolled logging since it will be a more generic solution. the only downside is it only works with emacs


@bja I ran across another one that proxies all the JDBC calls -- good to know there's more than one. Let me see if I can dig up the other project...

Shantanu Kumar18:08:23

Recently I added JDBC instrumentation feature to Preflex: — you can instrument a javax.sql.DataSource or java.sql.Connection and do custom stuff inside the wrapper


Here's the proxy / logging project I looked at before


It can do a lot more than just logging.


I'll say that I simply use a wrapper for jdbc/query and jdbc/execute! that takes honeysql maps and, conditionally based on a dynamic variable, will log the statement, explain, etc


it's a 5 minute hack and anyone who is already using a query building library probably has something similar (or at least the entry point for it)


i.e. I can say (query-runner db (-> (select :*) (from :foo) (where [:< :bar 10]))) but can also wrap anything being ran by query-runner or exec-runner using with-logged-query to logs (in my case with timbre)


if you are using honeysql, I'll also suggest that logging the honeysql map is possibly more useful than the generated sql, at least for puproses of inspecting/diffing/manipulating