v3.0.0

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 https://ktorm.liuwj.me/en/break-changes-in-ktorm-3.0.html

v2.7.2

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

v2.7.1

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

v2.6.1

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

v2.7

In Ktorm 2.7, we did a refactoring of the code. This refactoring deprecated Database.global 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 Database.global. More details can be found at https://ktorm.liuwj.me/en/about-deprecating-database-global.html

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 Table.select before:

// Old API
for (row in Employees.select()) {
    println(row[Employees.name])
}

This query uses Database.global, 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[Employees.name])
}

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. https://ktorm.liuwj.me/

Feel free to raise issues on GitHub if you have any questions.

v2.6

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: String
    var value1: String
    var 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

• Support defining entities as any kind of classes, such as data class or POJO, see https://ktorm.liuwj.me/en/define-entities-as-any-kind-of-classes.html
• Fix bug #33

Appreciation for the support and suggestions from @waluo

v2.4

• 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.

v2.3

• Documents for all public classes and functions.
• Throw DialectFeatureNotSupportedException while a feature is not supported by a dialect.
• Other optimizations and bug fixes.

v2.2

Add a logging facade and the slf4j dependency is removed. (#4)
Documents can be found at https://ktorm.liuwj.me/en/connect-to-databases.html#Logging