Skip to content

Latest commit

 

History

History
835 lines (661 loc) · 52.3 KB

CHANGELOG.md

File metadata and controls

835 lines (661 loc) · 52.3 KB

3.6.1

Migration Notes:

  • Memoization of Quats should improve performance of dynamic queries based on some profiling analysis. This change should not have any user-facing changes.

3.6.0

This description is an aggregation of the 3.6.0-RC1, RC2 and RC3 as well as several new items.

Migration Notes:

  • The Cassandra base UDT class io.getquill.context.cassandra.Udt has been moved to io.getquill.Udt.

  • When working with databases which do not support boolean literals (SQL Server, Oracle, etc...) infixes representing booleans will be converted to equality-expressions.

    For example:

    query[Person].filter(p => infix"isJoe(p.name)".as[Boolean])
    // SELECT ... FROM Person p WHERE isJoe(p.name)
    // Becomes> SELECT ... FROM Person p WHERE 1 = isJoe(p.name)
    

    This is because the aforementioned databases not not directly support boolean literals (i.e. true/false) or expressions that yield them.

    In some cases however, it is desirable for the above behavior not to happen and for the whole infix statement to be treated as an expression. For example

    query[Person].filter(p => infix"${p.age} > 21".as[Boolean])
    // We Need This> SELECT ... FROM Person p WHERE p.age > 21
    // Not This> SELECT ... FROM Person p WHERE 1 = p.age > 21
    

    In order to have this behavior, instead of infix"...".as[Boolean], use infix"...".asCondition.

    query[Person].filter(p => infix"${p.age} > 21".asCondition)
    // We Need This> SELECT ... FROM Person p WHERE p.age > 21
    

    If the condition represents a pure function, be sure to use infix"...".pure.asCondition.

3.6.0-RC3

3.6.0-RC2

Migration Notes:

  • When working with databases which do not support boolean literals (SQL Server, Oracle, etc...) infixes representing booleans will be converted to equality-expressions.

    For example:

    query[Person].filter(p => infix"isJoe(p.name)".as[Boolean])
    // SELECT ... FROM Person p WHERE isJoe(p.name)
    // Becomes> SELECT ... FROM Person p WHERE 1 = isJoe(p.name)
    

    This is because the aforementioned databases not not directly support boolean literals (i.e. true/false) or expressions that yield them.

    In some cases however, it is desirable for the above behavior not to happen and for the whole infix statement to be treated as an expression. For example

    query[Person].filter(p => infix"${p.age} > 21".as[Boolean])
    // We Need This> SELECT ... FROM Person p WHERE p.age > 21
    // Not This> SELECT ... FROM Person p WHERE 1 = p.age > 21
    

    In order to have this behavior, instead of infix"...".as[Boolean], use infix"...".asCondition.

    query[Person].filter(p => infix"${p.age} > 21".asCondition)
    // We Need This> SELECT ... FROM Person p WHERE p.age > 21
    

    If the condition represents a pure function, be sure to use infix"...".pure.asCondition.

  • This realease is not binary compatible with any Quill version before 3.5.3.

  • Any code generated by the Quill Code Generator with quote { ... } blocks will have to be regenerated with this Quill version if generated before 3.5.3.

  • In most SQL dialects (i.e. everything except Postgres) boolean literals and expressions yielding them are not supported so statements such as SELECT foo=bar FROM ... are not supported. In order to get equivalent logic, it is necessary to user case-statements e.g.

    SELECT CASE WHERE foo=bar THEN 1 ELSE 0`.

    On the other hand, in a WHERE-clause, it is the opposite:

    SELECT ... WHERE CASE WHEN (...) foo ELSE bar`

    is invalid and needs to be rewritten. Naively, a 1= could be inserted:

    SELECT ... WHERE 1 = (CASE WHEN (...) foo ELSE bar)

    Note that this behavior can disabled via the -Dquill.query.smartBooleans switch when issued during compile-time for compile-time queries and during runtime for runtime queries.

    Additionally, in certain situations, it is far more preferable to express this without the CASE WHEN construct:

    SELECT ... WHERE ((...) && foo) || !(...) && foo

    This is because CASE statements in SQL are not sargable and generally cannot be well optimized.

  • A large portion of the Quill DSL has been moved outside of QueryDsl into the top level under the io.getquill package. Due to this change, it may be necessary to import io.getquill.Query if you are not already importing io.getquill._.

3.6.0-RC1

Migration Notes:

  • This realease is not binary compatible with any Quill version before 3.5.3.

  • Any code generated by the Quill Code Generator with quote { ... } blocks will have to be regenerated with this Quill version if generated before 3.5.3.

  • In most SQL dialects (i.e. everything except Postgres) boolean literals and expressions yielding them are not supported so statements such as SELECT foo=bar FROM ... are not supported. In order to get equivalent logic, it is necessary to user case-statements e.g.

    SELECT CASE WHERE foo=bar THEN 1 ELSE 0`.

    On the other hand, in a WHERE-clause, it is the opposite:

    SELECT ... WHERE CASE WHEN (...) foo ELSE bar`

    is invalid and needs to be rewritten. Naively, a 1= could be inserted:

    SELECT ... WHERE 1 = (CASE WHEN (...) foo ELSE bar)

    Note that this behavior can disabled via the -Dquill.query.smartBooleans switch when issued during compile-time for compile-time queries and during runtime for runtime queries.

    Additionally, in certain situations, it is far more preferable to express this without the CASE WHEN construct:

    SELECT ... WHERE ((...) && foo) || !(...) && foo

    This is because CASE statements in SQL are not sargable and generally cannot be well optimized.

  • A large portion of the Quill DSL has been moved outside of QueryDsl into the top level under the io.getquill package. Due to this change, it may be necessary to import io.getquill.Query if you are not already importing io.getquill._.

3.5.3

Please skip this release and proceed directly to the 3.6.0-RC line. This release was originally a test-bed for the new Quats-based functionality which was supposed to be a strictly internal mechanism. Unfortunately multiple issues were found. They will be addressed in the 3.6.X line.

Migration Notes:`

  • Quill 3.5.3 is source-compatible but not binary-compatible with Quill 3.5.2.
  • Any code generated by the Quill Code Generator with quote { ... } blocks will have to be regenerated with Quill 3.5.3 as the AST has substantially changed.
  • The implementation of Quill Application Types (Quats) has changed the internals of nested query expansion. Queries with a querySchema or a schemaMeta will be aliased between nested clauses slightly differently. Given:
    case class Person(firstName:String, lastName:String)
    val ctx = new SqlMirrorContext(PostgresDialect, Literal)
    
    Before:
    SELECT x.first_name, x.last_name FROM (
      SELECT x.first_name, x.last_name FROM person x) AS x
    
    After:
    SELECT x.firstName, x.lastName FROM (
      SELECT x.first_name AS firstName, x.last_name AS lastName FROM person x) AS x
    
    Note however that the semantic result of the queries should be the same. No user-level code change for this should be required.

3.5.2

Migration Notes:

  • Much of the content in QueryDsl has been moved to the top-level for better portability with the upcoming Dotty implementation. This means that things like Query are no longer part of Context but now are directly in the io.getquill package. If you are importing io.getquill._ your code should be unaffected.
  • Custom decoders written for Finalge Postgres no longer require a ClassTag.

3.5.1

3.5.0

3.4.10

3.4.9

3.4.8

Documentation Updates:

Migration Notes:

  • Monix 3.0.0 is not binary compatible with 3.0.0-RC3 which was a dependency of Quill 3.4.7. If you are using the Quill Monix modules, please update your dependencies accordingly.

3.4.7

3.4.6

3.4.5

3.4.4

3.4.3

3.4.2

Migration Notes:

  • NamingStrategy is no longer applied on column and table names defined in querySchema, all column and table names defined in querySchema are now final. If you are relying on this behavior to name your columns/tables correctly, you will need to update your querySchema objects.

3.4.1

Migration Notes:

  • Nested sub-queries will now have their terms re-ordered in certain circumstances although the functionality of the entire query should not change. If you have deeply nested queries with Infixes, double check that they are in the correct position.

3.4.0

Migration Notes:

  • Infixes are now not treated as pure functions by default. This means wherever they are used, nested queries may be created. You can use .pure (e.g. infix"MY_PURE_UDF".pure.as[T]) to revert to the previous behavior. See the Infix section of the documentation for more detail.

3.3.0

Noteworthy Version Bumps:

  • monix - 3.0.0-RC3
  • cassandra-driver-core - 3.7.2
  • orientdb-graphdb - 3.0.21
  • postgresql - 42.2.6
  • sqlite-jdbc - 3.28.0

Migration Notes:

  • The returning method no long excludes the specified ID column from the insertion as it used to. Use the returningGenerated method in order to achieve that. See the 'Database-generated values' section of the documentation for more detail.
  • The == method now works Scala-idiomatically. That means that when two Option[T]-wrapped columns are compared, None == None will now yield true. The === operator can be used in order to compare Option[T]-wrapped columns in a ANSI-SQL idiomatic way i.e. None == None := false. See the 'equals' section of the documentation for more detail.

3.2.0

3.1.0

3.0.1

3.0.0

Migration notes

  • io.getquill.CassandraStreamContext is moved into quill-cassandra-monix module and now uses Monix 3.
  • io.getquill.CassandraMonixContext has been introduced which should eventually replace io.getquill.CassandraStreamContext.
  • Spark queries with nested objects will now rely on the star * operator and struct function to generate sub-schemas as opposed to full expansion of the selection.
  • Most functionality from JdbcContext has been moved to JdbcContextBase for the sake of re-usability. JdbcContext is only intended to be used for synchronous JDBC.

2.6.0

Migration notes

  • When the infix starts with a query, the resulting sql query won't be nested

2.5.4

2.5.0, 2.5.1, 2.5.2, and 2.5.3

Broken releases, do not use.

2.4.2

2.4.1

2.3.3

2.3.2

2.3.1

2.3.0

2.2.0

2.1.0

2.0.0

We're proud to announce the Quill 2.0. All bugs were fixed, so this release doesn't have any known bugs!

Fixes

#872, #874, #875, #877, #879, #889, #890, #892, #894, #897, #899, #900, #903, #902, #904, #906, #907, #908, #909, #910, #913, #915, #917, #920, #921, #925, #928

Migration notes

  • Sources now take a parameter for idiom and naming strategy instead of just type parameters. For instance, new SqlSource[MysqlDialect, Literal] becomes new SqlSource(MysqlDialect, Literal).
  • Composite naming strategies don't use mixing anymore. Instead of the type Literal with UpperCase, use parameter value NamingStrategy(Literal, UpperCase).
  • Anonymous classes aren't supported for function declaration anymore. Use a method with a type parameter instead. For instance, replace val q = quote { new { def apply[T](q: Query[T]) = ... } } by def q[T] = quote { (q: Query[T] => ... }

1.4.0

Migration notes

  • quill-async contexts: java.time.LocalDate now supports only date sql types, java.time.LocalDateTime - only timestamp sql types. Joda times follow this conventions accordingly. Exception is made to java.util.Date it supports both date and timestamp types due to historical moments (java.sql.Timestamp extents java.util.Date).
  • quill-jdbc encoders do not accept java.sql.Types as a first parameter anymore.

1.3.0

1.2.1

1.1.1

see migration notes below

Migration notes

  • Cassandra context property ctx.session.addressTranslater is renamed to ctx.session.addressTranslator

1.1.0

see migration notes below

Migration notes

  • JDBC contexts are implemented in separate classes - PostgresJdbcContext, MysqlJdbcContext, SqliteJdbcContext, H2JdbcContext
  • all contexts are supplied with default java.util.UUID encoder and decoder

1.0.1

1.0.0-RC1 - 20-Oct-2016

Migration notes

  • New API for schema definition: query[Person].schema(_.entity("people").columns(_.id -> "person_id") becomes querySchema[Person]("People", _.id -> "person_id"). Note that the entity name ("People") is now always required.
  • WrappedValue[T] no longer exists, Quill can now automatically encode AnyVals.

0.10.0 - 5-Sep-2016

see migration notes below

Migration notes

  • mappedEncoding has been renamed to MappedEncoding.
  • The way we add async drivers has been changed. To add mysql async to your project use quill-async-mysql and for postgre async quill-async-postgres. It is no longer necessary to add quill-async by yourself.
  • Action assignments and equality operations are now typesafe. If there's a type mismatch between the operands, the quotation will not compile.

0.9.0 - 22-Aug-2016

see migration notes below

Migration notes

  • The fallback mechanism that looks for implicit encoders defined in the context instance has been removed. This means that if you don't import context._, you have to change the specific imports to include the encoders in use.
  • context.run now receives only one parameter. The second parameter that used to receive runtime values now doesn't exist any more. Use lift or liftQuery instead.
  • Use liftQuery + foreach to perform batch actions and define contains/in queries.
  • insert now always receives a parameter, that can be a case class.
  • Non-lifted collections aren't supported anymore. Example: query[Person].filter(t => List(10, 20).contains(p.age)). Use liftQuery instead.
  • schema(_.generated()) has been replaced by returning.

0.8.0 / 17-Jul-2016

see migration notes below

Migration notes

This version introduces Context as a relacement for Source. This change makes the quotation creation dependent on the context to open the path for a few refactorings and improvements we're planning to work on before the 1.0-RC1 release.

Migration steps:

  • Remove any import that is not import io.getquill._
  • Replace the Source creation by a Context creation. See the readme for more details. All types necessary to create the context instances are provided by import io.getquill._.
  • Instead of importing from io.getquill._ to create quotations, import from you context instance import myContext._. The context import will provide all types and methods to interact with quotations and the database.
  • See the documentation about dependent contexts in case you get compilation errors because of type mismatches.

0.7.0 / 2-Jul-2016

0.6.0 / 9-May-2016

0.5.0 / 17-Mar-2016

0.4.1 / 28-Feb-2016

0.4.0 / 19-Feb-2016

0.3.1 / 01-Feb-2016

0.3.0 / 26-Jan-2016

0.2.1 / 28-Dec-2015

0.2.0 / 24-Dec-2015

0.1.0 / 27-Nov-2015

  • Initial release