Changelog History
Page 1
-
v3.16.3 Changes
Note
- This change is to allow ProtoQuill transition to BooPickle AST Serialization in https://github.com/zio/zio-protoquill/pull/72
-
v3.16.0 Changes
Migration Notes
- โก๏ธ This change removes the deprecated
EntityQuery.insert(CaseClass)
andEntityQuery.update(CaseClass)
APIs that have been updated toEntityQuery.insertValue(CaseClass)
andEntityQuery.updateValue(CaseClass)
. This is the only change in this release so that you can update when ready. This change is needed due to the upstream Dotty issue: lampepfl/dotty#14043.
- โก๏ธ This change removes the deprecated
-
v3.15.0 Changes
- โก๏ธ cassandra - update if exists
- โก๏ธ Change update to updateValue
Migration Notes
- โก๏ธ Similar to
EntityQuery.insert(CaseClass)
, the methodEntityQuery.update(CaseClass)
e.g.query[Person].update(Person("Joe", 123))
has been replaced withupdateValue
. The originalinsert
method has been deprecated and will be removed in an upcoming Quill release.
-
v3.13.0 Changes
- JAsync ZIO implementation
- cassandra-alpakka
- Need to change EntityQuery.insert(CaseClass) to EntityQuery.insertValue(CaseClass) for upstream Scala 3 issues.
- โก๏ธ Update ScalaJS to latest
- Work on removing tuple elaboration
- Option to Disable Nested Subexpansion
- ๐ Remove deprecated async modules
- ๐ Add Scala 3 cross-build for quill-engine
- ๐ Move quill-core-portable & quill-sql-portable to common quill-engine module
- Sheath leaf map clauses that cannot be reduced so still have their column in queries
Migration Notes
- The method
EntityQuery.insert(CaseClass)
e.g.query[Person].insert(Person("Joe", 123))
has been replaced withinsertValue
. The originalinsert
method has been deprecated and will be removed in the next Quill release. - ๐ The
quill-async
modules using Mauricio's deprecated library (here) have been removed. Please move to thequill-jasync
libraries as soon as possible. - โก๏ธ Quill for ScalaJS has been updated to ScalaJS 1.8.
- ๐
quill-core-portable
andquill-sql-portable
are now merged into a cross-builtquill-engine
module. - In 3.12.0 addition of field-aliases has been introduced in sub-queries but #2340
then occurred. A compile-time switch
-Dquill.query.subexpand=false
has been introduced to disable the feature until it can be fixed.
-
v3.12.0 Changes
- โฌ๏ธ cassandra - Datastax4x upgrade
- Implement dynamic query caching
- Fix Quat-based query schema rename issue
- โก๏ธ forUpdate via infix
- 0๏ธโฃ Disable file infra log by default
- Fix
QIO.apply
function type - โก๏ธ doc: update CODEGEN.md
Migration Notes - Datastax Drivers:
๐ง The Datastax drivers have been moved to Version 4, this adds support for many new features with the caveat that the configuration ๐ง file format must be changed. In Version 4, the Datastax standard configuration file format and properties ๐ง are in the HOCON format. They are used to configure the driver.
Sample HOCON:
MyCassandraDb { preparedStatementCacheSize=1000 keyspace=quill_test session { basic.contact-points = [ ${?CASSANDRA_CONTACT_POINT_0}, ${?CASSANDRA_CONTACT_POINT_1} ] basic.load-balancing-policy.local-datacenter = ${?CASSANDRA_DC} basic.request.consistency = LOCAL_QUORUM basic.request.page-size = 3 } }
๐ The
session
entry values and keys are described in the datastax documentation: ๐ง Reference configurationThe ZioCassandraSession constructors:
val zioSessionLayer: ZLayer[Any, Throwable, Has[CassandraZioSession]] = CassandraZioSession.fromPrefix("MyCassandraDb") run(query[Person]) .provideCustomLayer(zioSessionLayer)
โ Additional parameters can be added programmatically:
val zioSessionLayer: ZLayer[Any, Throwable, Has[CassandraZioSession]] = CassandraZioSession.fromContextConfig(LoadConfig("MyCassandraDb").withValue("keyspace", ConfigValueFactory.fromAnyRef("data"))) run(query[Person]) .provideCustomLayer(zioSessionLayer)
session.queryOptions.fetchSize=N
config entry should be replaced bybasic.request.page-size=N
testStreamDB { preparedStatementCacheSize=1000 keyspace=quill_test session { ... basic.request.page-size = 3 } ... }
๐ฒ Migration Notes - Query Log File:
0๏ธโฃ Production of the query-log file
queries.txt
has been disabled by default due to issues with SBT ๐ฒ and metals. In order to use it, launch the compiler JVM (e.g. SBT) with the argument-Dquill.log.file=my_queries.sql
๐ฒ or set thequill_log_file
environment variable (e.g.export quill_log_file=my_queries.sql
).Migration Notes - Monix:
The monix context wrapper
MonixJdbcContext.Runner
has been renamed toMonixJdbcContext.EffectWrapper
. The typeRunner
needs to be used by ProtoQuill to define quill-context-specific execution contexts. -
v3.11.0 Changes
- Implement
transaction
on outer zio-jdbc-context using fiber refs - Feature Request: write compile-time queries to a file
- ๐
transaction
supports ZIO effects with mixed environments - โก๏ธ Apple M1 Build Updates & Instructions
Migration Notes:
All ZIO JDBC context
run
methods have now switched from have switched their dependency (i.e.R
) fromHas[Connection]
toHas[DataSource]
. This should clear up many innocent errors that have happened because how thisHas[Connecction]
is supposed to be provided was unclear. As I have come to understand, nearly all DAO service patterns involve grabbing a connection from a pooled DataSource, doing one single crud operation, and then returning the connection back to the pool. The new JDBC ZIO context memorialize this pattern.The signature of
QIO[T]
has been changed fromZIO[Has[Connection], SQLException, T]
toZIO[Has[DataSource], SQLException, T]
. a new type-aliasQCIO[T]
(lit. Quill Connection IO) has been introduced that representsZIO[Has[Connection], SQLException, T]
.If you are using the
.onDataSource
command, migration should be fairly easy. Whereas previously, a usage of quill-jdbc-zio 3.10.0 might have looked like this:object MyPostgresContext extends PostgresZioJdbcContext(Literal); import MyPostgresContext._ val zioDS = DataSourceLayer.fromPrefix("testPostgresDB")
val people = quote { query[Person].filter(p => p.name == "Alex") }
MyPostgresContext.run(people).onDataSource .tap(result => putStrLn(result.toString)) .provideCustomLayer(zioDs)
In 3.11.0 simply remove the `.onDataSource` in order to use the new context. ```scala object MyPostgresContext extends PostgresZioJdbcContext(Literal); import MyPostgresContext._ val zioDS = DataSourceLayer.fromPrefix("testPostgresDB") val people = quote { query[Person].filter(p => p.name == "Alex") } MyPostgresContext.run(people) // Don't need `.onDataSource` anymore .tap(result => putStrLn(result.toString)) .provideCustomLayer(zioDs)
- If you are creating a Hikari DataSource directly, passing of the dependency is now also simpler. Instead having to pass
the Hikari-pool-layer into
DataSourceLayer
, just provide the Hikari-pool-layer directly.
From this:
def hikariConfig = new HikariConfig(JdbcContextConfig(LoadConfig("testPostgresDB")).configProperties) def hikariDataSource: DataSource with Closeable = new HikariDataSource(hikariConfig) val zioConn: ZLayer[Any, Throwable, Has[Connection]] = Task(hikariDataSource).toLayer >>> DataSourceLayer.live MyPostgresContext.run(people) .tap(result => putStrLn(result.toString)) .provideCustomLayer(zioConn)
To this:
def hikariConfig = new HikariConfig(JdbcContextConfig(LoadConfig("testPostgresDB")).configProperties) def hikariDataSource: DataSource with Closeable = new HikariDataSource(hikariConfig) val zioDS: ZLayer[Any, Throwable, Has[DataSource]] = Task(hikariDataSource).toLayer // Don't need `>>> DataSourceLayer.live` anymore! MyPostgresContext.run(people) .tap(result => putStrLn(result.toString)) .provideCustomLayer(zioConn)
If you want to provide a
java.sql.Connection
to a ZIO context directly, you can still do it using theunderlying
variable.object Ctx extends PostgresZioJdbcContext(Literal); import MyPostgresContext._ Ctx.underlying.run(qr1) .provide(zio.Has(conn: java.sql.Connection))
Also, when using an underlying context, you can still use
onDataSource
to go from aHas[Connection]
dependency back to aHas[DataSource]
dependency (note that it no longer has to bewith Closable
).object Ctx extends PostgresZioJdbcContext(Literal); import MyPostgresContext._ Ctx.underlying.run(qr1) .onDataSource .provide(zio.Has(ds: java.sql.DataSource))
Finally, that the
prepare
methods have been unaffected by this change. They still require aHas[Connection]
and have the signatureZIO[Has[Connection], SQLException, PreparedStatement]
. This is because in order to work with the result of this value (i.e. to work withPreparedStatement
), the connection that created it must still be open.
- Implement