Clojurians Log v2

Really liking the ResultBuilder design and its docs!

Glad to hear that! Thank you!

@serioga The with-transaction (and with-db-transction) syntax is meant to be a binding -- like any standard binding in Cojure, that folks are used to using. In real-world code that I've (over nearly nine years of maintaining Clojure wrappers for JDBC, it's pretty common to have

(jdbc/with-transaction [tx (some-expression)]
  ,,, tx ,,,)

(jdbc/with-transaction [tx sym]
  ,,, tx ,,,)

I'll admit that I made a mistake, syntax-wise, by allowing an options map as an optional third element in that binding. I've always regretted that (and I've often tried to think of ways to add a new, better syntax while deprecating the current third expression version, but keeping it around for backward compatibility).

I feel like jdbc/with-transaction [tx (some-expression)] does not fit well when (some-expression) return connection and not datasource

I don't understand what you mean by that.

It can be anything that with-transaction can get a connection from, on which to build the transaction. That's the same as execute!, execute-one!, and plan

the code

(jdbc/with-transaction [tx (get-connection)]
  ,,, tx ,,,)

No, you don't need to worry about that. It's automatic.

so when with-transaction works with datasource — everything works automatic when I work with connections, I need to wrap it with with-open and so on

It's exactly the same as how execute!, execute-one!, and plan work.

Oh... I see what you mean now... Yeah. But you can just pass a db-spec or a datasource, if you don't want to manage the connection.

it did not work in my tests and this is obvious because with-transaction can't know if connection can be closed at the end (because connection was provided outside)

But you can also hand it an existing connection and it will build the tx on top of it and then restore the connection.

See my response in the main channel.

But it's exactly like any other binding expression in Clojure. It's what people expect.

> But you can just pass a db-spec or a datasource, if you don't want to manage the connection. but I want. in most places I work with connections, and only in some places with transactions and I prefer to keep datasource hidden

OK, but I think you're fighting against the design of the library -- the docs emphasize making a DataSource (from a hash map or string, mostly) and using the datasource "everywhere". Both java.jdbc and next.jdbc work the same way -- the latter just tries harder to encourage that approach.

I'm totally fine with my wrapper around your macros

I'm not fighting, you are the author and you answered on my question in the past

I just mentioned that chosen design leaded to errors found today by linter.

It's just the "same" error as using the wrong variable anywhere in Clojure (and I've found the exact same error in other Clojure code that's not using JDBC).

Generally my question in the past was initiated by previous using of http://funcool.github.io/clojure.jdbc/latest/api/jdbc.core.html#var-atomic which was fine for me to use

> It's just the "same" error Usually using wrong variable leads to non-working code. In this case both vars are almost the same, so everything works instead of transactional processing, what really hard to mention 🙂