# Next.jdbc -- early access
**URL:** https://clojureverse.org/t/next-jdbc-early-access/4091
**Category:** Your Projects and Libraries
**Created:** [April 1, 2019, 6:27am UTC](https://clojureverse.org/t/next-jdbc-early-access/4091 "2019-04-01T06:27:45Z")
**Posts on this page:** 13
**Page:** 2
### Author:  [@seancorfield](https://clojureverse.org/u/seancorfield)
#### Post date: [April 6, 2019, 8:07pm UTC](https://clojureverse.org/t/next-jdbc-early-access/4091/21 "2019-04-06T20:07:56Z")
The current performance-focused route is via `reducible!`, for processing large result sets. That doesn’t create a hash map at all if you only use operations that lookup keys.
The other two scenarios that are goals of the library are fetch a single, fully-realized row and fetch a fully-realized sequence of rows. I’ve been talking to Ghadi about various options for allowing extensible row-building. If I go that route, it could produce hash maps with qualified keys, arrays of column names/row values, or anything else you want – including records – but qualified keywords will be the default choice because I believe that is the “right” default for most Clojure apps, especially those that also use spec.
I’d be interested in seeing what you have in mind for a separation of “compile” and “execute” (but not as a PR – and I’ll remind everyone of [https://github.com/seancorfield/next-jdbc/blob/master/CONTRIBUTING.md](https://github.com/seancorfield/next-jdbc/blob/master/CONTRIBUTING.md) at this point).
---
### Author:  [@ikitommi](https://clojureverse.org/u/ikitommi)
#### Post date: [April 8, 2019, 5:33am UTC](https://clojureverse.org/t/next-jdbc-early-access/4091/22 "2019-04-08T05:33:58Z")
Sorry, didn’t notice the CONTRIBUTING. Pushed my ideas with tests into [https://github.com/metosin/porsas](https://github.com/metosin/porsas). Hopefully some of the work can be joined later.
---
### Author:  [@seancorfield](https://clojureverse.org/u/seancorfield)
#### Post date: [April 18, 2019, 7:53am UTC](https://clojureverse.org/t/next-jdbc-early-access/4091/23 "2019-04-18T07:53:02Z")
I’ve reworked `next.jdbc` to include `RowBuilder` and `ResultSetBuilder` inspired by discussions with Ghadi. I’ve added an example of building `Fruit` records with a custom builder.
I’ve also moved the “sugar” functions to `next.jdbc.sql`, deleted `execute!` and `execute-one!` from `result-set` and reimplemented them as part of the `Executable` protocol so they no longer go through the `reducible!` path (which speeds them up quite a bit).
I’m not sure how much further I want to pursue performance at this point, given the flexibility I still want users of the library to have (and I am _not_ moving to a “precompile”/“execute”, beyond what you can do with creating a `PreparedStatement` and then executing/reducing it).
Feedback is welcome but I’m getting close to the point where I want to decide on a permanent home and make a release…
---
### Author:  [@seancorfield](https://clojureverse.org/u/seancorfield)
#### Post date: [April 22, 2019, 6:27am UTC](https://clojureverse.org/t/next-jdbc-early-access/4091/24 "2019-04-22T06:27:37Z")
See [Seancorfield/next.jdbc "1.0.0-alpha8"](https://v2.clojureverse.org/t/seancorfield-next-jdbc-1-0-0-alpha8/4181)
---
### Author:  [@vlaaad](https://clojureverse.org/u/vlaaad)
#### Post date: [May 10, 2019, 10:15pm UTC](https://clojureverse.org/t/next-jdbc-early-access/4091/25 "2019-05-10T22:15:41Z")
I don’t understand why do you need datafy at all, why not just return navigables that return other navigables? Your use of datafy seems like a no-op, and since datafy works on everything (returning identity by default), just returning navigables will do the same with fewer hops.
Another thing that slightly worries me is that datafy in this case is basically a memory leak: you keep a reference to a connection that is useful only during development (probably?).
---
### Author:  [@seancorfield](https://clojureverse.org/u/seancorfield)
#### Post date: [May 10, 2019, 11:05pm UTC](https://clojureverse.org/t/next-jdbc-early-access/4091/26 "2019-05-10T23:05:26Z")
For now, `datafy` is (almost) a no-op in this case – it takes a row in a result set and makes it navigable. The idiom is Thing -\> `datafy` -\> (navigable) data -\> `nav` -\> new Thing – that’s just how the protocols work and what REBL etc expect. Could I just make rows `Navigable` and rely on `datafy` being a no-op on them always? Maybe, but making them truly `Datafiable` feels like the “right thing to do” based on the intended idiomatic usage. The `datafy` behavior could be changed/enhanced down the line and this way we already have a hook for that.
As for the memory leak, the reference isn’t going to be any longer-lived than the data it is attached to – and the recommendation for `next.jdbc` is to pass around a _connectable_ such as a `Datasource` which would be much longer-lived anyway (if you’re using a connection pooled datasource, that’s what you’d be passing to most operations anyway).
It is one of the caveats of using REBL with this, that if you _do_ pass a `Connection` instead, and it gets `.close`d before REBL calls `nav`, you’ll get an error anyway.
---
### Author:  [@HolyJak](https://clojureverse.org/u/HolyJak)
#### Post date: [May 18, 2019, 12:44pm UTC](https://clojureverse.org/t/next-jdbc-early-access/4091/27 "2019-05-18T12:44:29Z")
Hello, I got this very confusing
> ClassCastException/CompilerException “java.lang.Character cannot be cast to java.lang.String” at “prepare.clj” 82
When I forgot to put the SQL into a vector:
```clojure
(let [my-datasource (get-datasource "jdbc:h2:tcp://localhost:1521/opt/h2-data/mb;MODE=Oracle;USER=sa")]
(with-open [connection (get-connection my-datasource)]
(execute-one! connection "SELECT ENABLED FROM organization"))) ; <- ERR
```
I realize this is alpha lib but anyway, perhaps something to put on the todo list, to
provide better error message here?
Thanks for the library, BTW!
---
### Author:  [@ikitommi](https://clojureverse.org/u/ikitommi)
#### Post date: [May 18, 2019, 4:11pm UTC](https://clojureverse.org/t/next-jdbc-early-access/4091/28 "2019-05-18T16:11:00Z")
I think it should be `(execute-one! connection ["SELECT ENABLED FROM organization"])`.
Edit: the question was about error messages. Could the functions allow both strings and vectors?
---
### Author:  [@seancorfield](https://clojureverse.org/u/seancorfield)
#### Post date: [May 18, 2019, 7:04pm UTC](https://clojureverse.org/t/next-jdbc-early-access/4091/29 "2019-05-18T19:04:14Z")
> [@ikitommi](#):
>
> Could the functions allow both strings and vectors?
No, I’m not making that mistake again [Clojure Don’ts: The Heisenparameter – Digital Digressions by Stuart Sierra](https://stuartsierra.com/2015/06/10/clojure-donts-heisenparameter)
I did it in `clojure.java.jdbc` and it propagated conditional logic through a lot of the library (since the API was so wide) and it made the specs harder to write and it also impacts performance: everyone pays the price just so some people can omit `[..]` around SQL statements that have no parameters.
`next.jdbc`’s API is much narrower so it wouldn’t be _as bad_ but it was a deliberate decision not to do this.
---
### Author:  [@seancorfield](https://clojureverse.org/u/seancorfield)
#### Post date: [May 18, 2019, 7:09pm UTC](https://clojureverse.org/t/next-jdbc-early-access/4091/30 "2019-05-18T19:09:42Z")
> [@HolyJak](#):
>
> I realize this is alpha lib but anyway, perhaps something to put on the todo list, to
> provide better error message here?
Options are:
- Add an `assert`
- Add a `:pre` condition
- Add an explicit conditional
- Provide specs and let developers `instrument` code in development if they want
The first three all incur a cost for everyone (the first two could be turned off for production but I don’t know how many people really do that) so I don’t want to go down that path.
The fourth is opt-in so I am more inclined to do that. If you had specs for `next.jdbc`, would that address your request @HolyJak?
---
### Author:  [@HolyJak](https://clojureverse.org/u/HolyJak)
#### Post date: [May 19, 2019, 10:07am UTC](https://clojureverse.org/t/next-jdbc-early-access/4091/31 "2019-05-19T10:07:18Z")
Good points. And yes, it would (providing the Getting started guide mentioned it and demonstrated how to turn them on.
---
### Author:  [@seancorfield](https://clojureverse.org/u/seancorfield)
#### Post date: [May 19, 2019, 11:27pm UTC](https://clojureverse.org/t/next-jdbc-early-access/4091/32 "2019-05-19T23:27:13Z")
>
---
### Author:  [@system](https://clojureverse.org/u/system)
#### Post date: [November 18, 2019, 11:41am UTC](https://clojureverse.org/t/next-jdbc-early-access/4091/33 "2019-11-18T11:41:47Z")
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.
[Previous page](https://clojureverse.org/t/next-jdbc-early-access/4091.md?page=1)