@seancorfield Hi, is that next.jdbc will not recogize {:datasource ...} as a connection?

@doglooksgood See https://cljdoc.org/d/seancorfield/next.jdbc/1.0.9/doc/migration-from-clojure-java-jdbc#primary-api

And https://cljdoc.org/d/seancorfield/next.jdbc/1.0.9/doc/readme#usage

@doglooksgood Did the documentation answer your question? And, if not, what would help make it clearer?

yeah, something confuse me. I've been using library conman for a while. this is a library to use with hugsql. conman provide a {:datasourcee DataSource} as connection. however recently I see conman has a commit say it support and switch to next.jdbc. but when using with next.jdbc, according to its example, it won't work. I can easily tweak the example code a little bit to make them work, but maybe I missed something?

according to the migration guide, I understand that next.jdbc narrow the options for db spec and it can now receive DataSource directly.

I don't know anything about conman. The next.jdbc docs do explain how to use it with HugSQL tho' as it has a new next.jdbc adapter in HugSQL 0.5.1.

next.jdbc also supports c3p0 and HikariCP for connection pooling out of the box.

Ah, luminus-framework/conman? Version 0.8.4 says it has switched to next.jdbc but there don't seem to be any doc updates with it... It just seems to have changed dependencies?

The examples in the readme are still using clojure.java.jdbc, not next.jdbc @doglooksgood -- you should open a GitHub issue on conman and ask them to update the readme!

yes, this is why I ask. I want to know if it is the situation that I should open an issue. I'll open a issue for that. conman is actually designed to be used for hugsql + mount. because mount don't do DI stuff, conman let you omit the db argument for sql function that generated by hugsql. anyway, I'll open a issue for this.

I don't like dynamic globals. I don't like Mount. 🙂

wait

https://github.com/luminus-framework/conman/issues/66#issuecomment-538084904

there is already an issue.😂

I should found this ealier

Ahah! There you go.

Frankly, I wouldn't bother with conman. Not sure why Mount even needs it? (despite Mount's global state approach)

it's not necessary, but the function generated by hugsql need a db argument. that need to be passed by hand.

Create a pooled datasource at startup -- using HikariCP and next.jdbc. Then just pass the datasource to HugSQL, per the next.jdbc docs.

And in the mount stop lifecycle, just .close the pooled datasource.

yes, I could do that. but conman simply wrap the api of hugsql, so I can write code like this:

(conman/bind-connection system/*db-conn* "hugsql/user.sql")
(find-user)

It's bad practice, IMO.

You can't easily write an app that uses multiple data sources. It makes testing harder. Global state is just horrible.

but If connection is injected into the handler, I will have to pass that to every place I will call a db function?

Yes, you should pass it explicitly into the db functions.

Global (mutable) state is a bad idea and should be avoided.

Be explicit about the dependency on the DB (or other resources) and your code will be much easier to test.

I'm glad to hear about this

We started over eight years ago with Clojure 1.3 alphas and we started with global state, like mount but home grown, because it was "easier" but it made for horrible maintenance down the road and we never do it now.

especially on how to test db function or how to test a part which contains a few db function calls.

We have 90,000 lines of Clojure at work and we still have some legacy code depending on those global datasources and it's nasty to work with.

We keep chipping away, rewriting it. And we regret that global state every day we touch that code!

I did not realize these maybe because my codebase is much smaller, it's just about 15k loc.

I also want to know what library you use to for scheduling jobs.

Our apps work with four or five different datasources. In particular we have an optimized readonly datasource that can be configured to read from slaves, so it's very useful to be able to switch code from one to the other -- simply by passing the desired datasource in.

Frankly, we use cron and run command line Clojure processes for that 🙂

But we also have quite a few Clojure background processes that just run 24x7 and poll database tables.

so you don't use something like quartz?

We don't need it.

Simple things work.

how you reuse the db functions? will you put all stuffs in a single project, build with different profiles(source paths)?

We have a monorepo with about 30 subprojects so we can build any combination of subprojects we want.

All driven by CLI/`deps.edn`.

We use depstar to build uber JAR files for automated deployment to production. We do not AOT compile anything.

great

I think I need re-thinking something

which library for system component management?

Component.

okay. thank you! these information help me a lot

Happy to answer pretty much any questions you might have about how we do stuff.

One day I might give a conference talk about it 🙂 or at least write more blog posts on http://corfield.org 🙂

let me know if you do

Can folks RT this please to get a bit more visibility, so I can get a bit more feedback? https://twitter.com/seancorfield/status/1184292968758251520