All Versions
73
Latest Version
Avg Release Cycle
-
Latest Release
-

Changelog History
Page 1

  • v3.16.3 Changes

    Note

  • v3.16.2 Changes

  • v3.16.1 Changes

  • v3.16.0 Changes

    Migration Notes

    • ⚡️ This change removes the deprecated EntityQuery.insert(CaseClass) and EntityQuery.update(CaseClass) APIs that have been updated to EntityQuery.insertValue(CaseClass) and EntityQuery.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.

  • v3.15.0 Changes

    Migration Notes

    • ⚡️ Similar to EntityQuery.insert(CaseClass), the method EntityQuery.update(CaseClass) e.g. query[Person].update(Person("Joe", 123)) has been replaced with updateValue. The original insert method has been deprecated and will be removed in an upcoming Quill release.

  • v3.14.1 Changes

  • v3.14.0 Changes

  • v3.13.0 Changes

    Migration Notes

    • The method EntityQuery.insert(CaseClass) e.g. query[Person].insert(Person("Joe", 123)) has been replaced with insertValue. The original insert 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 the quill-jasync libraries as soon as possible.
    • ⚡️ Quill for ScalaJS has been updated to ScalaJS 1.8.
    • 🔀 quill-core-portable and quill-sql-portable are now merged into a cross-built quill-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

    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 configuration

    The 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 by basic.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 the quill_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 to MonixJdbcContext.EffectWrapper. The type Runner needs to be used by ProtoQuill to define quill-context-specific execution contexts.

  • v3.11.0 Changes

    Migration Notes:

    All ZIO JDBC context run methods have now switched from have switched their dependency (i.e. R) from Has[Connection] to Has[DataSource]. This should clear up many innocent errors that have happened because how this Has[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 from ZIO[Has[Connection], SQLException, T] to ZIO[Has[DataSource], SQLException, T]. a new type-alias QCIO[T] (lit. Quill Connection IO) has been introduced that represents ZIO[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 the underlying 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 a Has[Connection] dependency back to a Has[DataSource] dependency (note that it no longer has to be with 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 a Has[Connection] and have the signature ZIO[Has[Connection], SQLException, PreparedStatement]. This is because in order to work with the result of this value (i.e. to work with PreparedStatement), the connection that created it must still be open.