Update to next.jdbc

[fvides]

Hi, nice project, many thanks!

I'm using it for the first time, and in my project already has next.jdbc as a dependency. Question: would a PR replacing clojure.java.jdbc for next.jdbc would be well received?

Thanks again!

[jimpil]

Hi there,

We have a few options here:

1. replacing clojure.java.jdbc with next.jdbc (per your request/idea). I'm not very fond of this approach because i don't want to break existing consumers, and also I'm not exactly sure the majority of users have migrated.
2. You can follow the code for core/postgres-atom, and create your own version which uses a custom backend that delegates to next.jdbc. This would be a great option if you're in a hurry.
3. Finally, we have what i think is the best option, provided it is feasible. If next.jdbc has kept mostly the same API then it would be trivial to try and require both namespaces at the top of duratom.utils.clj and let one of them succeed. If you have the time to investigate that, it would be fantastic - otherwise I'll try to get to it over the weekend. It's basically 6 fns that we need (with-db-transaction,update!,insert!,db-do-commands, create-table-ddl & query).

Let me know of what you think, and thanks for the suggestion 👍

[fvides]

Hi

You are right in making non breaking changes, I thought about that after writing my suggestion. I concur in that next.jdbc is not widely used as of now, but I think it will be. AFAIK is not a drop-in replacement as you can see at their wiki page about migrating so option 3 is not feasible IMHO.

Maybe the solution could be extract the database options into a separate module, with a protocol defining with the needed functions and three implementations, one for c.j.jdbc, other for next.jdbc and one empty for when there is none of them. Or maybe I'm overthinking it (happens from time to time :)) I could give it a try if you want.

Thanks!