Skip to content

Update doobieVersion to v1.0.0-RC10 #133

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update doobieVersion to v1.0.0-RC10 #133

wants to merge 1 commit into from

Conversation

@renovate
Copy link
Contributor

@renovate renovate bot commented Jun 21, 2023 •
edited
Loading

This PR contains the following updates:

Package Update Change
org.tpolecat:doobie-core patch 1.0.0-RC2 -> 1.0.0-RC10
org.tpolecat:doobie-h2 patch 1.0.0-RC2 -> 1.0.0-RC10
org.tpolecat:doobie-hikari patch 1.0.0-RC2 -> 1.0.0-RC10
org.tpolecat:doobie-postgres patch 1.0.0-RC2 -> 1.0.0-RC10
org.tpolecat:doobie-refined patch 1.0.0-RC2 -> 1.0.0-RC10

Release Notes

typelevel/doobie (org.tpolecat:doobie-core)

v1.0.0-RC10

Compare Source

This release is a small release, with a minor change and some dependency updates.

Dependency updates

Also thanks to various other project internal improvements from @​xuwei-k and @​sharmaakshay177!

New Contributors

Full Changelog: typelevel/doobie@v1.0.0-RC9...v1.0.0-RC10

v1.0.0-RC9

Compare Source

Fixes & Changes
Documentation
Dependency updates
Internal changes
New Contributors

Full Changelog: typelevel/doobie@v1.0.0-RC8...v1.0.0-RC9

v1.0.0-RC8

Compare Source

This release contains some small improvements/bugfixes

New
  • Allow constructing Read from a list of underlying instances by @​jatcwang in #​2195
  • Feature: Allow customizing individual steps of query execution by @​ulfryk in #​2154
  • Scala 3 OrElse: Remove unncessary by-name parameter #​2194
Bug fixes
Documentation

Full Changelog: typelevel/doobie@v1.0.0-RC7...v1.0.0-RC8

v1.0.0-RC7

Compare Source

[!IMPORTANT]
When upgrading, please skip 1.0.0-RC6. It is considered a broken release due to issues with unexpected implicit prioritization, which we've fixed in RC7.
Apologies to those that updated RC6 when it first came out!

Release notes below include all changes since 1.0.0-RC5.

Notable features / changes
Query Cancellation

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

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

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.

We have significantly reworked the internals of Read/Write derivation to allow opt-in semi-auto and automatic derivation.

  • 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 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

[!IMPORTANT]
For Scala 3, we highly recommend using explicit derivation and avoid any automatic derivation (i.e. no imports of doobie.implicits.* or import doobie.generic.auto.*). Scala 3's implicit search algorithm doesn't seem to follow implicit prioritization the same way as Scala 2 compile, which means its implicit search is very expensive with automatic derivation (Leading to long compile times and "Implicit search problem too large." error for bigger case classes). See #​2214 for more information.

Scala 2+:

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

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

As part of this derivatino rework, it is now possible to obtain a Read[Option[A]]/Write[Option[A]] instance
directly from Read[A]/Write[A].

Related PRs:

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

In previous releases, doobie typecheck only checks against the integer (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 for legacy reasons

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.
When constructing instances (e.g. Get.Basic.one(..)) you can pass the expected vendor type to checkedVendorType parameter, or None if you don't need or want to check against the vendor type.

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.

3. Make doobie.implicits.javasql instances available by default

doobie.implicits.javasql has now been removed. You can safely remove any import doobie.implicits.javasql.* as these instances are now available without any import.

4. Better typechecked array enum columns (Postgres-only)

If you have a column which is an array of enum type, you should switch to use doobie.postgres.implicits.arrayOfEnum
to define the Meta instance on the application side for better typechecking.

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:

Other changes
Notable dependency updates
Internal/doc changes
New Contributors

Big thanks to all new and regular contributors!

Full Changelog: typelevel/doobie@v1.0.0-RC5...v1.0.0-RC7

v1.0.0-RC6: 1.0.0-RC6

Compare Source

Warning: We have an issue in this release related to automatic derivation not using explicitly defined instances (See #​2104). Please refrain from using this release and skip to 1.0.0-RC7 when it is out.

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:

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.
When constructing instances (e.g. Get.Basic.one(..)) you can pass the expected vendor type to checkedVendorType parameter, or None if you don't need or want to check against the vendor type.

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.

3. Make doobie.implicits.javasql instances available by default

doobie.implicits.javasql has now been removed. You can safely remove any import doobie.implicits.javasql.* as these instances are now available without any import.

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:

Other notable changes
Dependency updates
Internal/doc changes
New Contributors

Full Changelog: typelevel/doobie@v1.0.0-RC5...v1.0.0-RC6

v1.0.0-RC5: 1.0.0-RC5

Compare Source

What's New
Bug fixes and improvements
New Contributors

Full Changelog: typelevel/doobie@v1.0.0-RC4...v1.0.0-RC5

v1.0.0-RC4

Compare Source

v1.0.0-RC3

Compare Source

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)
  • Depends on cats-effect 3.5 & fs2 3.7
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)

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: 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 #​1729
  • Add weaver test framework integration by @​danielkarch in #​1668
  • Added doobie.hikari.HikariTransactor.fromConfigAutoEc which automatically creates/configures the ExecutionContext which awaits connections from the pool, following best practices. By @​sideeffffect in #​1690
Binary Compatibility

v1.0.0-RC3 is NOT binary compatible

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot force-pushed the renovate/doobieversion branch 2 times, most recently from d32963b to 0851ca9 Compare June 27, 2023 12:42
@renovate renovate bot force-pushed the renovate/doobieversion branch from 0851ca9 to 6398e94 Compare June 29, 2023 16:11
@renovate renovate bot force-pushed the renovate/doobieversion branch 4 times, most recently from c414794 to 1a83dab Compare July 13, 2023 18:28
@renovate renovate bot force-pushed the renovate/doobieversion branch 3 times, most recently from 7019b87 to 09ce415 Compare July 25, 2023 14:49
@renovate renovate bot force-pushed the renovate/doobieversion branch from 09ce415 to 3c42507 Compare July 28, 2023 19:17
@renovate renovate bot force-pushed the renovate/doobieversion branch 3 times, most recently from c768f80 to 814afd4 Compare August 11, 2023 10:35
@renovate renovate bot force-pushed the renovate/doobieversion branch 2 times, most recently from 359e42d to 509f272 Compare August 22, 2023 22:08
@renovate renovate bot force-pushed the renovate/doobieversion branch 3 times, most recently from 93836ae to 4f16c61 Compare August 30, 2023 22:51
@renovate renovate bot force-pushed the renovate/doobieversion branch 5 times, most recently from 7ab8669 to a07716c Compare September 8, 2023 03:32
@renovate renovate bot force-pushed the renovate/doobieversion branch 3 times, most recently from 0217b9e to 44fef23 Compare September 15, 2023 13:42
@renovate renovate bot force-pushed the renovate/doobieversion branch 3 times, most recently from 6f30048 to 605277b Compare September 19, 2023 14:12
@renovate renovate bot force-pushed the renovate/doobieversion branch 2 times, most recently from cec7cc5 to c987957 Compare April 27, 2024 14:26
@renovate renovate bot force-pushed the renovate/doobieversion branch 4 times, most recently from a19385a to 43e444f Compare May 7, 2024 10:22
@renovate renovate bot force-pushed the renovate/doobieversion branch 3 times, most recently from f4e4316 to e558489 Compare May 12, 2024 18:45
@renovate renovate bot force-pushed the renovate/doobieversion branch from e558489 to 0dd61b6 Compare May 16, 2024 17:58
@renovate renovate bot force-pushed the renovate/doobieversion branch 6 times, most recently from 7413855 to e46534d Compare July 29, 2024 00:03
@renovate renovate bot force-pushed the renovate/doobieversion branch 3 times, most recently from 237d445 to 1eebe8d Compare August 1, 2024 15:55
@renovate renovate bot force-pushed the renovate/doobieversion branch from 1eebe8d to 2db8b0b Compare September 18, 2024 13:12
@renovate renovate bot changed the title Update doobieVersion to v1.0.0-RC5 Update doobieVersion to v1.0.0-RC6 Sep 18, 2024
@renovate renovate bot force-pushed the renovate/doobieversion branch from 2db8b0b to 78fa989 Compare February 9, 2025 08:36
@renovate renovate bot changed the title Update doobieVersion to v1.0.0-RC6 Update doobieVersion to v1.0.0-RC7 Feb 9, 2025
@renovate renovate bot force-pushed the renovate/doobieversion branch from 78fa989 to bcad582 Compare February 26, 2025 02:58
@renovate renovate bot changed the title Update doobieVersion to v1.0.0-RC7 Update doobieVersion to v1.0.0-RC8 Feb 26, 2025
@renovate renovate bot force-pushed the renovate/doobieversion branch from bcad582 to f2a3ae9 Compare April 18, 2025 14:03
@renovate renovate bot changed the title Update doobieVersion to v1.0.0-RC8 Update doobieVersion to v1.0.0-RC9 Apr 18, 2025
@renovate renovate bot force-pushed the renovate/doobieversion branch from f2a3ae9 to 9f46574 Compare July 14, 2025 01:36
@renovate renovate bot changed the title Update doobieVersion to v1.0.0-RC9 Update doobieVersion to v1.0.0-RC10 Jul 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants