Should hugsql switch to next.jdbc by default ?

[ieugen]

From what I've read clojure.java.jdbc, while good is on maintenace and will probably not be receiving new features.
next.jdbc receives more love.

IMO it would make sense to have hugsql ship by default with next.jdbc .

I've noticed this on hugsql page:

HugSQL has protocol-based adapters supporting multiple database libraries and ships with adapters for clojure.java.jdbc (default), next.jdbc, and clojure.jdbc.

https://www.hugsql.org/

and

This library is mature and stable. It is widely used and its use is described in many books and tutorials. It will continue to get bug fixes and minor releases. Based on my experience using and maintaining this library, I've created a faster, more modern JDBC wrapper called next.jdbc. I consider it to be the "next generation" of clojure.java.jdbc but it exposes a different API -- a better API, I think.

https://github.com/clojure/java.jdbc

[csummers]

This a good question and one that I considered when we added the next.jdbc adapter. A few thoughts around this issue:

The trade-offs for any team/project encountering this switch would vary, but doing so would potentially break lots of code bases in unexpected ways. For this reason alone, I think it is unlikely that the default clojure.java.jdbc adapter is replaced with next.jdbc.

However, having a default in the first place, while meant to make things easier for users, may have been a mistake. A more likely scenario is that we remove any "magic" and do not load a default adapter at all. Instead, we would require that users add the appropriate adapter library to their deps and set the adapter on startup. This would level the user experience across all adapters, and also bring to light the fact that there is an underlying library doing the jdbc work. Some of the questions/issues over the years have come from users' lack of awareness of this detail.

It's still a big change to move to no default, but I think the breakage would be a "stop the world" event vs. a potentially quiet "something's not working" surprise. A big change like this would need to happen in a major release. I'd also like to consider if and how to make any change like this as painless as possible.

I'll keep this open as we think on this.

[ieugen]

I also think that having a no-default and letting users chose either one version is a good option.
This can be as easy as having a dependency on the classpath and selecting the implementation when configuring.
I would like to have the option of choosing what gets on the classpath.