Fork me on GitHub
#sql
<
2020-04-05
>
teodorlu14:04:42

Really liking the ResultBuilder design and its docs!

parrot 12
👍 4
seancorfield17:04:57

Glad to hear that! Thank you!

seancorfield18:04:08

@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 ,,,)
and less common to see
(jdbc/with-transaction [tx sym]
  ,,, tx ,,,)

seancorfield18:04:10

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).

serioga18:04:27

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

seancorfield18:04:39

I don't understand what you mean by that.

seancorfield18:04:40

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

serioga18:04:21

the code

(jdbc/with-transaction [tx (get-connection)]
  ,,, tx ,,,)
requires me to care about closing got connection which is not an issue when you work with datasource

seancorfield18:04:21

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

serioga18:04:35

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)

seancorfield18:04:09

See my response in the main channel.

serioga18:04:53

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

seancorfield18:04:01

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

seancorfield18:04:59

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.

seancorfield18:04:49

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

serioga18:04:58

yes, and here I have conn and tx inside block and can be confused what to use and what for

serioga18:04:39

This is exactly your errors found with linter today

serioga18:04:58

yes, and here I have conn and tx inside block and can be confused what to use and what for

seancorfield18:04:28

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

serioga19:04:16

> 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

seancorfield19:04:33

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.

serioga19:04:10

I'm totally fine with my wrapper around your macros

serioga19:04:48

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

serioga19:04:40

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

seancorfield19:04:20

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).

serioga19:04:23

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

serioga19:04:45

> 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 🙂