This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-07-23
Channels
- # announcements (2)
- # beginners (165)
- # boot (11)
- # cider (11)
- # clj-kondo (7)
- # cljdoc (1)
- # cljsrn (5)
- # clojure (120)
- # clojure-dev (21)
- # clojure-europe (3)
- # clojure-france (1)
- # clojure-italy (62)
- # clojure-nl (8)
- # clojure-spec (26)
- # clojure-uk (40)
- # clojuredesign-podcast (1)
- # clojurescript (3)
- # cursive (2)
- # data-science (2)
- # datomic (10)
- # emacs (2)
- # figwheel-main (1)
- # fulcro (17)
- # graphql (5)
- # hoplon (5)
- # jackdaw (15)
- # jobs (2)
- # juxt (1)
- # luminus (5)
- # off-topic (1)
- # onyx (11)
- # pathom (4)
- # pedestal (1)
- # re-frame (4)
- # reagent (11)
- # reitit (1)
- # remote-jobs (5)
- # shadow-cljs (48)
- # spacemacs (2)
- # specter (4)
- # sql (24)
- # tools-deps (25)
- # vim (82)
Would it work to have some kind of next.jdbc.edn
configuration file which will configure default column-fn/table-fn/result-set builder?
is there a possibility to insert-multi!
vector of maps?
is there a way to specify jdbc-url
?
I am trying to run h2 db in memory using jdbc-url jdbc:h2:mem:test
Found answer in source code:
h2:mem - org.h2.Driver
-- for an in-memory database`
@kirill.salykin Not sure what you're suggesting with next.jdbc.edn
-- can you elaborate?
Yes, the default builders for queries still bothers me
For insert-multi!
-- a vector of maps could be massaged into a vector of column names and vectors of row values but the "gotcha" is what happens if the keys are not all identical across all of those maps? That's why insert-multi!
doesn't support that option. You can select and get cols + rows back via the as-arrays
builders so that is a natural fit.
Thanks, did like this
Because as you said it is not possible to attach it to connection - maybe it makes sense to have config file?
For jdbc-url
-- get-datasource
accepts a String
which is the JDBC URL. And, yes, :dbtype "h2:mem"
is an in-memory H2 database and is supported.
@kirill.salykin So you're suggesting that next.jdbc
read an (optional) .edn
file from the classpath and use the defaults in there across the whole library? That would mean adding global variables to hold the default config which I really don't want to do.
Yes, exactly
K, will think about other option)
Do you think it is worth dig into?
Are you ok with this?
The caveat is performance: any global config solution must not affect performance, and must "do the right thing" in terms of threads.
In other words, anyone who does not use this config feature should pay zero cost.
Makes sense
Do you think it is possible to extend using data source protocol ?
One possible approach would be to provide a "wrapper" namespace, that exposes the core API + the SQL builder API but has a config mechanism that applies defaults at that level, not within the core of the library.
https://github.com/seancorfield/next-jdbc/issues/49 What do you think about this approach?
I responded. I don't understand how you think that would work.
I spent a fair bit of time trying to support a "global config" flowing from the db-spec hash map down into the datasource and the connections but it wasn't really tenable (you need to wrap Connection
and find a zero cost way to conditionally get config from both that wrapped version and still support the native Connection
type!).
Thanks, will look into it