Fork me on GitHub
Jakub Holý (HolyJak)11:10:50

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:

    (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))))

    (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).

Jakub Holý (HolyJak)06:10:25

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

Jakub Holý (HolyJak)11:10:15

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 :'(

😞 1

I'll give this some thought. I may introduce a with-connection macro for this (which execute-batch! could also use).