Changelog History
Page 3
-
v0.7.1
October 04, 2019 -
v0.7.0 Changes
May 26, 2019This is a compatibility-breaking release, although most source code should compile unmodified.
The big changes are improvements in resource safety:
- Replaced
MonadError
-basedguarantee
withbracket
, which prevents potential resource leakage when using cancelable IO; and improves transactor resource safety by usingResource
. The migration guide contains slightly more information. Thanks Sam Guymer for these updates! - ⚡️
Fragment
concatenation and derived combinators likeFragments.in
are now stacksafe, so you can now have giganticIN
clauses. This required API changes inParam
,Fragment
,Update[0]
andQuery[0]
but these should not affect most users.
🆕 New features:
- At long last there is a
doobie-quill
module that allows constructingConnectionIO
values via Quill quotes. See the new book chapter for examples. Many thanks to Alex Ioffe and Chris Davenport for their assistance!
And an assortment of other improvements:
- Postgis has been upgraded to v2.3.0. Thanks Erlend Hamnaberg!
- Added support for Scala 2.13.0-M5, many thanks to Sam Guymer for setting this up!
TypeTag
constraint onAnalyzable
has been relaxed toWeakTypeTag
. Thanks nigredo-tori!- New syntax allows
.transact
onOptionT
andEitherT
ofConnectionIO
, rolling back in the failure cases. Thanks Julien Truffaut! - Postgres now supports arrays of Scala
BigDecimal
. Thanks Nicolas Rémond! - Most calls to
throw
have been replaced withraiseError
, which allows doobie to work with effect types that don't catch. Thanks Sam Guymer! - Some things in the build were preventing doobie from cooperating with the community build. This has been fixed, thanks Seth Tisue!
Text[Char]
instance was added for PostgresCOPY FROM STDIN
. Thanks Dermot Haughey!- You can now create a
HikariTransactor
from aHikariConfig
. Thanks Yuriy Badalyantc! - Thanks to Harry Laoulakos and Daan Hoogenboezem for documentation updates!
Fragment
combinators now parenthesize arguments so associativity in Scala is reflected in generated SQL. Thanks Katrix!
- Replaced
-
v0.7.0-M5
May 07, 2019 -
v0.7.0-M4
April 20, 2019 -
v0.7.0-M3
February 19, 2019 -
v0.7.0-M2
January 17, 2019 -
v0.7.0-M1
January 04, 2019 -
v0.6.0 Changes
Many thanks to Arber Shabhasa, Bjørn Madsen, Chris Davenport, Cody Allen, Dmitry Polienko, Kai(luo) Wang, Kevin Walter, Mark Canlas, and Quang Le Hong for their contributions to this release.
💥 :exclamation: This is a major update with breaking changes. Please read the following notes carefully.
Transactors and Threading
Prior to 0.6.x doobie had nothing to say about threading; it was up to users to shift interpreted
IO
programs onto dedicated pools if desired. This has changed. We now identify three distinct execution contexts that are relevant to database applications.- All non-blocking work is performed on the execution context identified by
ContextShift[F]
. If you are usingIOApp
(which you should) this instance is provided for you. All interpreters (and thus all transactors) need this instance on construction. - Requesting a JDBC connection is a blocking operation, so to avoid deadlock these requests cannot be placed in competition with running programs (which need to make progress in order to finish up and return their connections to the pool). Therefore we need a distinct, bounded, blocking execution context for the single purpose of awaiting database connections. All transactors that use a connection pool will require this execution context to be specified. ⏱ 1. All JDBC primitive operations are [potentially] blocking, so we need a distinct, typically unbounded (since the connection context above provides a logical bound) execution context for scheduling these operations. All transactors that use a connection pool will require this execution context to be specified.
✅ For convenience we provide an
ExecutionContexts
module that providesResource
s yielding the kinds ofExecutionContext
s that will tend to be useful for the scenarios above. Note thatDriverManagerTransactor
provides an unbounded number of connections and is unsuitable for production use anyway, so we do not require the blocking pools here (it uses an unbounded pool internally). Fine for testing but don't use it in real life.See the book chapter on Managing Connections for more information and examples.
Streams and Resources
In 0.5.x we provided some single-element
Stream
s that would emit values and guarantee resource cleanup. This has been generalized asResource
in cats-effect 1.x, and all such constructors (H2Transactor.newH2Transactor
for example) now useResource
rather thanStream
. You can useStream.resource(rsrc)
to regain the old functionality if desired.Splitting of read/write functionality.
Prior to the 0.6.x series we provided two typeclasses for bidirectional type mapping:
Meta
defined nullable mappings between column/parameter values and scala types.Composite
defined null-safe mappings between column/parameter vectors and scala types.
Starting with version 0.6.0 type mappings are unidirectional:
Meta
has been split intoGet
andPut
typeclasses, for reads and writes of column/parameter values, respectively.Composite
has been split intoRead
andWrite
typeclasses, for reads and writes of column/parameter vectors, respecitively.
👍 Note that
Meta
does still exist, but only as a mechanism for introducingGet/Put
pairs. An implicitMeta[A]
induces both an implicitGet[A]
and an implicitPut[A]
, and the old mechanism ofMeta[A].imap(...)(...)
is still supported for this purpose. Thexmap
method has been replaced with parametricimap
andTypeTag
-constrainedtimap
. Prefertimap
when possible because it yields better diagnostic information when typechecking queries.To summarize:
0.5.x 0.6.x Notes [A: Meta]
[A: Get : Put]
Or just one, depending on usage. [A: Composite]
[A: Read : Write]
Or just one, depending on usage. Meta[A].xmap(..)
Meta[A].timap(...)
Or imap
when aTypeTag
is unavailable.Composite[A].xmap(...)
Read[A].map(...)
Write[A].contramap(...)
This takes two steps now. Please refer to book chapter on Custom Mappings and the
examples
project for more details.Other Changes
- postgres-circe module created exposing Get and Put instances for
io.circe.Json
- ⬆️ upgraded to cats-effect 1.0 and fs2 1.0
- All non-blocking work is performed on the execution context identified by
-
v0.5.4
December 07, 2018 -
v0.5.3 Changes
⚡️ Minor updates, see below.
- Updated to refined 0.9, fs2 0.10.4, Hikari 3.1.0, ScalaCheck 1.14.0, and Specs2 4.2.0.
- ➕ Added
.execWith
method toFragment
, allowing for custom handling of the associated statement. - ➕ Added
pure
to generated algebras, so you can now sayFC.pure(1)
instead of1.pure[ConnectionIO]
if you like. Thanks wedens! - ➕ Added an example of generic DAOs for simple schemas. See
Orm.scala
in theexample
project. - ⚡️ Minor doc updates.
🚀 This is the last planned release in the 0.5.x series. Work will start soon on 0.6!