Functional JDBC layer for Scala.
WeakAsync.liftIO by @armanbilge in https://github.com/tpolecat/doobie/pull/1910
syncStep in WeakAsync.liftK by @armanbilge in https://github.com/tpolecat/doobie/pull/1906
Full Changelog: https://github.com/tpolecat/doobie/compare/v1.0.0-RC4...v1.0.0-RC5
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:
def run(logEvent: LogEvent): M[Unit]
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
LogHandler[M] when constructing your Transactor (or pass a None if you don't want to log events)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)
All PostgreSQL users should migrate to using doobie.postgres.JavaTimeInstances which has stricter type-checking to help you catch errors. For example, it enforces that the corresponding column type of an java.time.Instant must be TIMESTAMP WITH TIME ZONE.
Thanks @guymers!
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
doobie.util.fragments.*)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 parenthesisFor 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.
andOpt/orOpt, which now return an Option[Fragment].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**v1.0.0-RC3 is NOT binary compatible
copyIn (#1512 by @oyvindberg)This is the first 1.0.0 release candidate, built on Cats-Effect 3 on the main branch.
Doobie is now published for Scala 3.0.0!
doobie-munit)Doobie now integrates with the https://scalameta.org/munit test framework via the doobie-munit module.
See https://tpolecat.github.io/doobie/docs/13-Unit-Testing.html on how to use it!
Big thanks to @Kazark and @alejandrohdezma for contributing this integration!
Support for Scala 3 RC3, Drops RC1. (Note that Doobie 1.x integrates with cats-effect 3.x)
Now published for Scala 3 RC3
The previous version (v0.12.0) upgraded Hikari to v4, which pulls in slf4j v2, which is incompatible with the version most people are using. So this version reverts that upgrade. No other changes.
This release removes Scala 3.0.0-M2 and adds Scala 3.0.0-RC1.
Note that we refer below to changes since v0.10.0. The 0.11 series was never released.
doobie.postgres.implicits._Confusion around which date time instances to use has been a constant issues to Doobie users, and in this release we aim to make this easier.
If you're using PostgreSQL, import doobie.postgres.implicits._ will now provide you with the correct Meta instances for java.time types, based on pgjdbc's native support for them. You should remove any doobie.implicits.javatime or doobie.implicits.legacy imports as they will likely cause ambiguous implicits error.
If you're using other databases, you can keep using the current instances that you explicitly import. You can also submit a PR with a similar setup as the postgres module to make everyone life easier :)
If you see deprecation warnings about import doobie.implicits.javatime._, you can change it to import doobie.implicits.javatimedrivernative._ (Same behaviour and instances - just a better name for clarity)
IOAnalysisMatchers (Dmitry Polienko)