@metametadata I thought long and hard about the high-level syntactic sugar functions and decided to keep them in the top-level API because they handle things differently in some situations -- now that I've clarified how per-row functions worked in the core reducing API. If you look at the latest source, hopefully that will make sense.

Thanks for heads up. I like that they have "Syntactic sugar" comments now.

What is your favourite solution to keep fresh DB for tests during developing? flyway ? Something similar?

Also to keep updated DB on production

@kwladyka we're using migratus but flyway should be fine; only concern is if ddl is not transactional, if you have multiple servers running the same code you need to ensure it wont blow up if two of them do the same migration

we reset the db for each test; bear in mind if you're using component you can even have a different db per test and run tests in parallel

We use joplin and write migrations in plain Clojure for max flexibility. For testing there's a second db running with optimized settings and before every test every table is TRUNCATEd.

should jdbc-next be fully async? any function that do a IO call return a future channel?

but isn't JDBC API inherently synchronous?

ah, maybe you really mean jdbc-next and not next.jdbc

Async JDBC is not on table yet. It's something I'll look at in due course.

Hello Everyone! I am dealing with an issue right now, I would like to execute a query case insensitive… here is my code:

(defn save-to-primavera [db params]
  (as-> {:insert-into :Bookings
         :values      [params]} %
        (honeysql/format %)
        (jdbc/execute! db % {:return-keys true})))

@tomas.arruda Are you actually getting an error from that? I can't reproduce it locally.

One thing you can try is (honeysql/format % :quoting :ansi) since it may be PostgreSQL itself that is changing Bookings to bookings without it being quoted.