Fork me on GitHub
#sql
<
2019-07-23
>
kirill.salykin08:07:07

Would it work to have some kind of next.jdbc.edn configuration file which will configure default column-fn/table-fn/result-set builder?

kirill.salykin12:07:11

is there a possibility to insert-multi! vector of maps?

kirill.salykin13:07:13

is there a way to specify jdbc-url? I am trying to run h2 db in memory using jdbc-url jdbc:h2:mem:test

kirill.salykin14:07:16

Found answer in source code: h2:mem - org.h2.Driver -- for an in-memory database`

seancorfield16:07:16

@kirill.salykin Not sure what you're suggesting with next.jdbc.edn -- can you elaborate?

kirill.salykin16:07:59

Yes, the default builders for queries still bothers me

seancorfield16:07:26

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.

kirill.salykin16:07:34

Thanks, did like this

kirill.salykin16:07:31

Because as you said it is not possible to attach it to connection - maybe it makes sense to have config file?

seancorfield16:07:39

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.

seancorfield17:07:16

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

kirill.salykin17:07:34

K, will think about other option)

kirill.salykin17:07:34

Do you think it is worth dig into?

kirill.salykin17:07:44

Are you ok with this?

seancorfield17:07:04

The caveat is performance: any global config solution must not affect performance, and must "do the right thing" in terms of threads.

seancorfield17:07:59

In other words, anyone who does not use this config feature should pay zero cost.

kirill.salykin17:07:28

Do you think it is possible to extend using data source protocol ?

seancorfield17:07:50

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.

seancorfield17:07:04

I responded. I don't understand how you think that would work.

seancorfield17:07:04

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

kirill.salykin17:07:57

Thanks, will look into it