All Versions
Latest Version
Avg Release Cycle
47 days
Latest Release
1082 days ago

Changelog History
Page 1

  • v3.2.0 Changes

    October 08, 2020

    πŸ“¦ Package Name Changed to org.ktorm

    Finally, we have our own domain and the official website becomes

    Accordingly, starting from Ktorm 3.2, we have changed our group ID to org.ktorm, so you need to modify your Maven dependency:

    \<dependency\> \<groupId\>org.ktorm\</groupId\> \<artifactId\>ktorm-core\</artifactId\> \<version\>3.2.0\</version\> \</dependency\>

    Or Gradle:

    compile "org.ktorm:ktorm-core:3.2.0"

    πŸ“¦ Package names are also changed to org.ktorm.*, so you also need to modify your import statements:

    import org.ktorm.database.\*import org.ktorm.dsl.\*import org.ktorm.entity.\*import org.ktorm.schema.\*

    With the only two steps, you have completed all the migration work to version 3.2. Everything should work well as there are no other changes apart from this.

  • v3.1.0 Changes

    September 19, 2020

    ⬆️ Upgrade to Kotlin 1.4

    ⬆️ To use the new features of Kotlin, we've upgraded its version to 1.4.10, which brings some changes to us:

    Explicit API mode to ensure we don't expose some internal things accidentally.

    πŸ‘ Contract support for database.useConnection { .. } & database.useTransaction { .. } to let the compiler know our callback functions are called in place exactly once.

    πŸ—„ Deprecation of mapColumnsN & aggregateColumnsN functions. As Kotlin 1.4 supports overload resolution by lambda return type, we don't need these functions anymore, mapColumns & aggregateColumns is enough.

    database.employees .filter { it.departmentId eq 1 } .mapColumns { tupleOf(, } .forEach { (id, name) -\>println("$id:$name") }

    ⚑️ Entity Based Update Function

    In Ktorm 3.1, we provide an update function that can update all the non-null properties of an entity object to the database. Using this function, the entity object is not required to be associated with a table first. That means, comparing to flushChanges, we don’t have to obtain an entity object from the database first before performing the update. The usage is as follows:

    val employee = Employee { id = 5 job = "engineer" salary = 100} database.employees.update(employee)

    Generated SQL:

    update t\_employee set job = ?, salary = ? where id = ?

    πŸ”¨ Syntax Refactoring of Insert & Update DSL

    Previously, we inserted a record into the table like this:

    database.insert(Employees) { to "jerry" it.job to "trainee" it.managerId to 1 it.hireDate to it.salary to 50 it.departmentId to 1}

    Here, we used to "jerry" to set the name to jerry in the closure. And the to function is a member of AssignmentsBuilder, but not the to function used to create Pair instances of Kotlin standard lib.

    🚚 It is very easy for users to get confused with these two functions, so in Ktorm 3.1, we provide another set function as an alternative. The to function is marked deprecated and will be removed in the future. You can learn the new syntax here

    database.insert(Employees) { set(, "jerry") set(it.job, "trainee") set(it.managerId, 1) set(it.hireDate, set(it.salary, 50) set(it.departmentId, 1) }

    πŸ›  Other Optimizations and Bug Fixes

    • βž• Add ShortSqlType. #160
    • βž• Add MySQL IF function. #163
    • πŸ‘Œ Support mixed-case column names & auto case transform. #175
    • πŸ‘ Allow specify PostgreSQL insertOrUpdate conflict columns. #181
    • πŸ‘Œ Support select .. for update. #69
    • πŸ‘Œ Support catalog & schema in table definition. #89, #154, #183
    • Check max column name length. #122
    • πŸ›  Fix timestamp fraction bug. #130
    • ⚑️ Update the syntax of defining JSON columns from json("foo", typeRef<List<Int>>) to json<List<Int>>("foo").
  • v3.0.0 Changes

    June 16, 2020

    Some break changes in Ktorm 3.0:

    • 🚚 Completely remove the deprecated global database APIs and provide equivalent things in a new module ktorm-global.
    • πŸ‘‰ Use = instead of property delegation to define columns.
    • Query doesn't implement Iterable anymore.
    • πŸ‘Œ Support compound primary keys.

    ⚑️ In addition to the break changes above, there are also many updates from enthusiasts in the open source community, thanks for their contributions:

    • ⚑️ MySQL bulkInsert function supports on duplcate key update. Thank @hangingman
    • PostgreSQL hstore data type and a series of operators for it. Thank @arustleund
    • πŸ‘ ktorm-jackson supports simple Jackson annotations, like @JsonProperty, @JsonAlias, @JsonIgnore. Thank @onXoot

    πŸ‘€ For more details about the new version, see

  • v2.7.2 Changes

    February 22, 2020

    πŸ›  Fix the bug that entities can not be inserted when Spring support enabled. vincentlauvlwj/ktorm-example-spring-boot#2

  • v2.7.1 Changes

    February 10, 2020

    πŸ›  Fix the bug that transactions don't commit while we are using a non-local return in the inlined useTransaction block. #90

  • v2.7 Changes

    February 02, 2020

    πŸ”¨ In Ktorm 2.7, we did a refactoring of the code. This refactoring deprecated and a series of functions implemented based on it, making users explicitly specify the Database instances to use while performing database operations, instead of implicitly use More details can be found at

    🚚 > Note that these APIs are still available in version 2.7, but they have been marked as @Deprecated and will be completely removed in the future.

    In previous versions, although Database.connect returns a new created Database object, we usually ignore it because Ktorm automatically saves it to an internal global variable. But now, we have to define a variable by ourselves to hold the return value:

    val database = Database.connect("jdbc:mysql://localhost:3306/ktorm?user=root&password=\*\*\*")

    We used to create queries by the extension function before:

    // Old APIfor (row in { println(row[]) }

    πŸ‘€ This query uses, obtaining all records from Employees table, which is indeed very implicit as you can see. Now we have to specify the database instance explicitly and use the syntax of database.from(..).select(..) to create queries:

    for (row in database.from(Employees).select()) { println(row[]) }

    Here is another example:

    val t = Employees.aliased("t") database .from(t) .select(t.departmentId, avg(t.salary)) .groupBy(t.departmentId) .having { avg(t.salary) greater 100.0 } .forEach { row -\>println("${row.getInt(1)}:${row.getDouble(2)}") }

    As for sequence APIs, we used to create sequence objects via asSequence before, and now we just need to change it to sequenceOf. For example:

    val employees = database.sequenceOf(Employees).toList()

    Another example using sequenceOf:

    val employees = database .sequenceOf(Employees) .filter { it.departmentId eq 1 } .filter { it.managerId.isNotNull() } .sortedBy { it.salary } .toList()

    πŸ”¨ These are the two most significant changes in this refactoring. The documents on Ktorm's official website have now been updated for version 2.7. You can refer to the latest documents for what you are interested in.

    πŸ†“ Feel free to raise issues on GitHub if you have any questions.

  • v2.6.1 Changes

    February 10, 2020

    πŸ›  Fix the bug that transactions don't commit while we are using a non-local return in the inlined useTransaction block. #90

  • v2.6 Changes

    November 02, 2019

    πŸ‘Œ Support Running on Android Devices (#22)

    πŸ‘ Now, Ktorm is available for Android SQLite with the support of SQLDroid driver. And technically, any other JDBC driver is also supported (if you really need them running on Android).

    ⚑️ Update JVM Target to 1.6

    ⚑️ For maximum compatibility, we updated the compiler option -jvm-target to 1.6. This option is used to specify the version of the generated JVM bytecode. Moreover, to support running on Android and JDK 1.6, we added three SqlType implementations, they supports java.sql.Timestamp, java.sql.Date and java.sql.Time, because JSR-310 is not available on those platforms.

    πŸ‘Œ Support Multiple Bindings on One Column

    Now, we can bind a column to multiple properties by calling the bindTo or references functions continuously. In this way, when an entity object is retrieved from the database, the value of this column will be filled to each property it binds.

    interface Config : Entity\<Config\> { val key: Stringvar value1: Stringvar value2: String}object Configs : Table\<Config\>("t\_config") { val key by varchar("key").primaryKey().bindTo { it.key } val value by varchar("value").bindTo { it.value1 }.bindTo { it.value2 } }

    In the example above, we bound the value column to both value1 and value2, so the values of these two properties would be the same in an entity object obtained from the database.

    ⚑️ > Please note that multiple bindings are only available for query operations. When we are inserting or updating an entity, the first binding will prevail, and other bindings will be ignored.

    πŸ‘Œ Support Column Alias DSL (by @waluo, #37)

    Now, we can assign aliases to the selected columns of a query and use them in subsequent clauses such as group by and having, just like the as keyword in SQL. Here is an example. This query selects departments whose average salary is greater than 100, then returns the average salaries along with their department’s IDs.

    val deptId = Employees.departmentId.aliased("dept\_id")val salaryAvg = avg(Employees.salary).aliased("salary\_avg")Employees .select(deptId, salaryAvg) .groupBy(deptId) .having { salaryAvg greater 100.0 } .forEach { row -\>println("${row[deptId]}:${row[salaryAvg]}") }

    Generated SQL:

    select t\_employee.department\_id as dept\_id, avg(t\_employee.salary) as salary\_avg from t\_employee group by dept\_id having salary\_avg \> ?

    πŸ›  Other Optimizations and Bug Fixes

    • πŸ”¨ Refactoring the implementation of QueryRowSet.
    • πŸ‘Œ Support SQL Server datetimeoffset data type.
    • Max/min aggregation functions' type arguments should be Comparable instead of Number (#46).
  • v2.5 Changes

    August 24, 2019

    πŸ‘ Appreciation for the support and suggestions from @waluo

  • v2.4 Changes

    June 26, 2019
    • ⬆️ Upgrade Kotlin version to 1.3.40.
    • πŸ”Š Auto detect the third-party logging framework we are using from the classpath, and delegate Ktorm's logs to it. #15
    • πŸ‘‰ Use JDK ServiceLoader to find a dialect. Now we don't have to specify the dialect parameter explicitly while creating Database instances. #5
    • βž• Add match and against functions for MySQL fulltext search, translated to its match ... against ... syntax. #25
    • βž• Add insertOrUpdate function for PostgreSQL's data "upsert", translated to its on conflict (key) do update set syntax. #26
    • πŸ›  Other optimizations and bug fixes.