next.jdbc question: Am I right how this fns work? (connection/->pool ...) - the same as (jdbc/get-connection ds) but keep many connections (jdbc/get-connection ds) - open 1 connection and keep it open, if closed then re-open (get-datasource ...) - open and close 1 connection for each query

(let [log-ds (next.jdbc/with-logging d println println)]
    (jdbc/execute! log-ds ["SHOW timezone"]))
Syntax error compiling at (src/crypto_trading/db/integrant.clj:1:195).
No such var: next.jdbc/with-logging

@kwladyka https://cljdoc.org/d/com.github.seancorfield/next.jdbc/1.2.780/api/next.jdbc#with-logging

Make sure you're not pulling in an older next.jdbc as a transitive dependency.

1.2.659 I am curious why clj -M:outdated --upgrade doesn’t upgrade it higher

:outdated {:extra-deps {com.github.liquidz/antq {:mvn/version "1.6.0"}}
                      :main-opts ["-m" "antq.core"]}}

No idea. I don't let tools modify my deps.edn. I get the report and do it manually.

What's in your deps.edn?

seancorfield/next.jdbc {:mvn/version "1.2.659"}

:outdated {:extra-deps {com.github.liquidz/antq {:mvn/version "1.6.0"}}
                      :main-opts ["-m" "antq.core"]}}

> Could not find artifact seancorfield:next.jdbc:jar:1.2.780 in central (https://repo1.maven.org/maven2/)

com.github.seancorfield/next.jdbc

ah…. thank you

I am curious how many other deps I use like that…

I'm surprised antq didn't spot the group ID change -- it's been pretty good about reporting those for me. Clojars changed their group name policy about a year ago and several libraries changed their group IDs to reflect that. I double-published for a while and then announced I was going to stop double-publishing.

The README explicitly calls that out BTW:

The documentation on GitHub is for develop since the 1.2.780 release -- see the CHANGELOG and then read the corresponding updated documentation on GitHub if you want. Older versions of next.jdbc were published under the seancorfield group ID and you can find older seancorfield/next.jdbc documentation on cljdoc.org.

yes I remember this policy change, but some libraries changed namespace, some not…. not easy to follow

Read the README? 🙂

each of library? 🙂

(you should always read the readme and changelog whenever you are considering updating a library)

yes, but I use clj -M:outdated --upgrade to detect if there is something to update

Which is a bad idea. Because it will change things without giving you any idea of what changed in a library.

It could easily upgrade a library to some incompatible version.

I mean I use it to detect and then I can read vs read all deps readme and then update.

the most important is: with-logs works now! 🙂

The change to the coordinates was documented in 1.1.643, BTW:

1.1.643 -- 2021-03-06

Change coordinates to com.github.seancorfield/next.jdbc (although new versions will continue to be deployed to seancorfield/next.jdbc for a while -- see the Clojars Verified Group Names policy).

Anyways, glad you have it working now. Also, please stop using depstar and switch to tools.build (per the depstar README) 🙂

I know, I should notice it, but I didn’t.

(just in case you're relying on antq to update depstar and hadn't noticed that it is deprecated/archived now 🙂 )

this one I noticed

the last question: Can I somehow preview for debug purpose the final raw SQL for

(jdbc/execute! log-ds ["SELECT ?::timestamptz" "2022-01-01 00:00:00"])

not very important right now but today I wanted to know what is the final form of Instant in SQL query. Finally I found it in Postgres logs. So I could see if the query contain 2022-04-04 02:00:00+02 vs 2022-04-04 00:00:00+00.

Any good practice to make it UTC always and always? I see there is :serverTimezone for jdbc-url but I am not sure about the effect and don’t know if it will work with pool.

Does it need to be a parameter? Can you just do

now() at time zone 'utc'

Re: raw SQL actually sent to the DB -- no, JDBC doesn't make that available.

Re: timezones -- my recommendation is always to have your database and the server it runs on and your JVM and the server that runs on all set to UTC timezone.

^^^^

I can but then I will have to write at time zone 'utc' in each query.

this

always that

Re: timezones -- my recommendation is always to have your database and the server it runs on and your JVM and the server that runs on all set to UTC timezone.

That depends on your setup - some people run the dbs on developer laptops

I use docker-compose for third party software deps, so not problem here

FWIW, we always have &characterEncoding=UTF-8&serverTimezone=UTC in our JDBC URLs at work (for QA/production -- for dev/CI we omit serverTimezone and rely on local time since we don't control the TZ for those "servers").

But I am writing crypto currency bot which will play this game with my own money and if somehow something will break about timezone everything can end very bad

Is it possible to set {:builder-fn jdbc-rs/as-unqualified-maps} on pool or by default?

Thank you for help. I am going sleep. Goodnight.

@kwladyka Look at with-options in the docs -- but also the caveats around calling get-connection and with-transaction on that (since those unwrap the options and you need to rewrap them). Although, I strongly recommend trying to get used to and work with the qualified keys in what next.jdbc returns -- and only switching to unqualified keys if you need to expose that data to some external system.

I interpret it as (jdbc/with-options pool {:builder-fn rs/as-unqualified-lower-maps}) work also with pool. Once again thank you. Goodnight.

Great everything works perfect.