v1.0.0-RC3

[jatcwang]

Java 11 & major dependency updates

• The minimum Java version is now 11
• slf4j version is now 2.x (In order to update to latest HikariCP)

Effectful Logging & Transactor-level logging

In previous versions Doobie supports SQL statement logging via LogHandler. However, it has the slightly awkward interface of final case class LogHandler(unsafeRun: LogEvent => Unit) which makes it difficult to integrate with pure FP logging libraries.

We have reworked how logging works, with the two major difference being:

• LogHandler now runs in an effect i.e. def run(logEvent: LogEvent): M[Unit]
• Each Transactor[M] now has a single LogHandler[M] attached to it, in order to align the effect type.

To recover some of the previous functionality of per-query logging logic, you can call .queryWithLabel/.updateWithLabel (instead of .query/.update) to attach a String label to each query.
This label will be set for each LogEvent, which your LogHandler can then use to differentiate the queries being logged. (e.g. use it for metrics)

For more advanced use case where you want to pass more structured contextual information for logging purposes, you can use IOLocal (The docs on logging has an example)

Big thanks to @oyvindberg for the implementation of effectful LogHandler and @george-wilson-rea for adding query labels

Basic migration steps

• Add a LogHandler[M] when constructing your Transactor (or pass a None if you don't want to log events)
• Replace queryWithLogHandler/updateWithLogHandler with queryWithLabel/updateWithLabel

Tightening Postgres java.time instance typecheck

In #1735 / #1736, we tightened Meta instances for PostgreSQL java.time instances to reflect what the postgres-jdbc driver actually allows. For example, typechecking a query that tries to map a java.time.OffsetDateTime to a VARCHAR column in the database will now fail.

Instance for ZonedDateTime has also been removed as it is misleading (PostgreSQL does not support a timestamp type that stores the timezone)

Thanks @guymers!

doobie-hikari: Now automatically creates the Connect ExecutionContext

doobie.hikari.HikariTransactor#fromConfig/fromHikariConfig previously requires you to pass in a connectEC: ExecutionContext parameter used when awaiting a connection from the hikari connection pool.
Since the general best practice is to set this fixed-size pool to your hikari connection pool size, we now automatically create this ExecutionContext for you based on hikariConfig.getMaximumPoolSize.

If you want to use your own connectEC like previous versions, you can use doobie.hikari.HikariTransactor#fromConfigCustomEC/fromHikariConfigCustomEC instead.

By @sideeffffect in #1690 and #1745

Improved composability and safety of fragment helpers (doobie.util.fragments.*)

• when calling methods like and/or, we now wrap the resulting expression in parenthesis.
  This prevents scenarios where the boolean logic generated by and/or can be influenced by its surroundings due to the lack of parenthesis

For example, previously the code fr"cond1 AND ${or(cond2, cond3)}" evaluates to the SQL cond1 AND cond2 OR cond3, which is most likely not equivalent to the user's intention of cond1 AND (cond2 OR cond3) and will behave differently for certain cond1/2/3 values.

Basic migration steps

• Fix compile errors from andOpt/orOpt, which now return an Option[Fragment].
• Carefully check use of and/or/andOpt/orOpt if they are used in conjunction with other AND/OR. If you were previously relying on fragment helpers NOT wrapping the resulting expression in parenthesis, you should adjust your code to maintain to old behaviour**

Other additions

• Add Semigroup and Monoid instances for ConnectionIO and friends by @Fristi in Add Monoid and Semigroup instances for ConnectionIO (conflicts resolved) #1729
• Add weaver test framework integration by @danielkarch in Added weaver module #1668
• Added doobie.hikari.HikariTransactor.fromConfigAutoEc which automatically creates/configures the ExecutionContext which awaits connections from the pool, following best practices. By @sideeffffect in Add functions for creating HikariTransactor that automatically create connectEC #1690

Binary Compatibility

v1.0.0-RC3 is NOT binary compatible

---

This discussion was created from the release v1.0.0-RC3.

[cosmir17]

Hello Doobie maintainers,

I recently noticed that the RC3 version of Doobie has been announced on Github. This is fantastic news, and I'm eager to utilize the latest improvements in my projects.

However, upon checking the Maven Repository, I've been unable to locate the new release. Is it possible that the RC3 version has not yet been uploaded to the Maven Repository?

I understand these processes can take time, and I appreciate all the hard work you put into maintaining this valuable library. If you could provide a status update on the Maven release, it would be greatly appreciated.

Thank you for your time and consideration.

Best regards,

Sean

[jatcwang]

@cosmir17 I'm able to see the artifact since release e.g. https://repo1.maven.org/maven2/org/tpolecat/doobie-core_2.13/1.0.0-RC3/

Have pulled and used it in my own projects too so perhaps it's something on your end?

[cosmir17]

Indeed, it's present. I've just tried it on my local machine, and my sbt managed to fetch the new version.
However, the new version doesn't appear to be displayed on the following page for some reason:
https://mvnrepository.com/artifact/org.tpolecat/doobie-core

Perhaps it will be updated automatically at a later time.

[jatcwang]

I believe https://mvnrepository.com is an indexing service so there's always going to be some lag.

[cosmir17]

I don't know how to close this discussion.

[jatcwang]

No need :) It's open for all RC3 woes