Download Latest Version v1.0.0-RC10 source code.tar.gz (447.2 kB)
Email in envelope

Get an email when there's a new version of doobie

Home / v1.0.0-RC6
Name Modified Size InfoDownloads / Week
Parent folder
1.0.0-RC6 source code.tar.gz 2024-09-17 434.4 kB
0
1.0.0-RC6 source code.zip 2024-09-17 672.0 kB
0
README.md 2024-09-17 13.1 kB
0
Totals: 3 Items   1.1 MB 0

Query Cancellation

Query cancellation has been implemented via calling PreparedStatement#close() on fiber cancellation.

Big thanks to @TalkingFoxMid and contributions from @satorg @armanbilge @jatcwang!

Related PRs: [#2079] [#2088]

Opt-in automatic derivation

Automatic derivation has been the (non-configurable) default in Doobie since the start. While convenient, it can lead to long compile times because Read/Write/Get/Put instances are derived every time it is needed.

For those who want shorter compile times, we have now made automatic derivation opt in!

  • import doobie.implicits.* will enable automatic derivation (maintaining source compatibility to ease migration).
  • import doobie.generic.auto.* to explicitly enable automatic derivation. Compared to import doobie.implicits.* this brings just the implicits/givens necessary for automatic derivation
  • Instances for tuples are still automatically derived for convenience
  • To switch to explicitly derived instances, change your import doobie.implicits.* to import doobie.syntax.all.* and gradually fix compile errors by deriving instances explicitly (see below):

To derive instances explicitly:

Scala 3:

case class Foo(a: String, b: Int) derives Read

Scala 2+:

case class Foo(a: String, b: Int)

object Foo {
  implicit val read: Read[Foo] = Read.derived
}

Related PRs: * Opt in auto derivation by @guymers / @jatcwang in https://github.com/tpolecat/doobie/pull/1967 * Fix instance derivation by @jatcwang in https://github.com/tpolecat/doobie/pull/2037 * Make tuple Read/Write instances available without an import by @jatcwang in https://github.com/tpolecat/doobie/pull/2070

Better type-checking with JDBC vendor types (For java.time.* and more)

In previous releases, doobie typecheck only checks against the int enum returned by java.sql.ResultSetMetaData#getColumnType (java.sql.Types). However this is inadequate for two reasons:

  • java.sql.Types doesn't cover many other possible database-specific types (e.g. JSON column type)
  • JDBC drivers often return the wrong java.sql.Types, often due to legacy

For example, for a TIMESTAMP WITH TIME ZONE column Postgres JDBC driver will report that it has the type java.sql.Types.TIMESTAMP (surprising as java.sql.Types.TIMESTAMP_WITH_TIMEZONE exists).

PostgreSQL Data Type getColumnType() getColumnTypeName()
TIMESTAMP Types.TIMESTAMP "TIMESTAMP"
TIMESTAMP WITH TIME ZONE Types.TIMESTAMP "TIMESTAMPTZ"

This means by just using the result from getColumnType typechecking couldn't differentiate between a TIMESTAMP WITH TIME ZONE column vs TIMESTAMP (WITHOUT TIMEZONE) column - which has serious implications for correctness of your program if one uses the wrong column type!

Fortunately, we can see that getColumnTypeName does differentiate between the two column types.

To help improve typechecking for java.time.* types (and generally), we have made the following changes:

1. Get and Put can now specify vendor column type name

When creating a Get or Put instance, the vendor type name can now be specified so typechecking will check against it.

2. Move java.time.* instances into database modules

java.time.* instances are moved to their database-specific modules to handle differences in databases and their drivers.

doobie module import
doobie-postgres doobie.postgres.implicits.*
doobie-mysql doobie.mysql.implicits.*

For other databases that support Java 8 time types, you can continue to use import doobie.implicits.javatimedrivernative.* but there's no check against vendor type names.

Related PRs:

Logging for streaming and updateMany queries

Query/Update which now allow queries ran through Query#stream and Update#withGeneratedKeys to be logged. As part of this work, doobie.hi.FC module also have 3 new functions: stream, executeWithResultSet and executeWithoutResultSet. Old functions that does not log (such as doobie.hi.FC.updateWithGeneratedKeys) has been deprecated and will be removed by 1.0.

Related PRs: * Fix logging for streaming and updateMany by @jatcwang in https://github.com/tpolecat/doobie/pull/2064

Other notable changes

Dependency updates

Internal/doc changes

New Contributors

Full Changelog: https://github.com/tpolecat/doobie/compare/v1.0.0-RC5...v1.0.0-RC6

Source: README.md, updated 2024-09-17