This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-06
Channels
- # babashka (19)
- # beginners (68)
- # calva (9)
- # cider (27)
- # clj-kondo (64)
- # clj-on-windows (2)
- # cljdoc (8)
- # clojure (11)
- # clojure-europe (58)
- # clojure-italy (1)
- # clojure-nl (23)
- # clojure-uk (5)
- # clojurescript (9)
- # cryogen (18)
- # cursive (14)
- # data-science (17)
- # emacs (6)
- # gorilla (6)
- # graphql (1)
- # gratitude (2)
- # holy-lambda (10)
- # introduce-yourself (1)
- # jackdaw (3)
- # jobs (1)
- # leiningen (2)
- # malli (3)
- # missionary (33)
- # off-topic (21)
- # pedestal (7)
- # polylith (8)
- # quil (3)
- # random (1)
- # releases (1)
- # remote-jobs (7)
- # shadow-cljs (18)
- # specter (1)
- # sql (8)
Hi @seancorfield! I see that next.jdbc.default-options
is not public and its wrapped-connection?
is marked as "internal". Yet I need to use it (or re-implement it) to know that I do not need to call (jdbc/get-connection my-defaults-options-wrapping-connection)
, which would fail. Am I doing st. wrong?
I have:
(cond
(instance? java.sql.Connection ds)
(rs/datafiable-result-set (tables (.getMetaData ds)))
(next.jdbc.default-options/wrapped-connection? ds)
(rs/datafiable-result-set (tables (.getMetaData (:connectable ds))))
:else
(with-open [conn (jdbc/get-connection ds)]
(rs/datafiable-result-set (tables (.getMetaData conn)))))
Hmm, I would have expected such code to already know whether it had a Connection
or something else but I guess this sort of thing might become more common as more people use with-options
(which we avoid as much as possible at work).
I see. So what do you use instead to ensure all execute! etc have the same builder-fn etc?
We don't. Some of our code uses the default builder (new code) -- that's what we try to do for as much code as possible. Some of our code uses as-unqualified-maps
for compatibility with older code (or as-unqualified-lower-maps
in a few cases). Some of our code uses snake-kebab-opts
. Since it's usually on a per-namespace basis, we def default-jdbc-opts
at the top of such namespaces and provide that in each call.
But in general we try to stick to the default options (i.e., none).
Thanks! I'm writing code that needs to work across DBs and given that Oracle, as far as I remember, doesn't provide what you need to return qualified keys, I need to use unqualified keys everywhere, ie not the default :'(
I'll give this some thought. I may introduce a with-connection
macro for this (which execute-batch!
could also use).