阿里国际数字商业集团 Lazada 首页 & 内容团队，正在热聘 Java、C++ 服务端 P6 岗位，Base 广州，欢迎自荐或推荐

我们正在寻找对技术充满热情的你，共同打造电商领域的智能化未来！无论你是专注于高性能推荐引擎的架构设计与优化，还是热衷于大模型 Agent 的落地应用与推理性能提升，抑或是探索生成式推荐与导购助手的创新场景，这里都有广阔的舞台。我们期待具备扎实计算机基础、熟悉算法与数据结构、热爱解决复杂问题的你加入，一起用技术创新驱动业务变革，定义行业新高度！

• 岗位 1：LAZADA-Java高级开发工程师-推荐系统方向
• 岗位 2：LAZADA-Java高级开发工程师-LLM应用方向
• 岗位 3：LAZADA-C++高级开发工程师-推荐&大模型引擎方向

作为 Kotlin 服务端开发者，你可能已经厌倦使用 MyBatis 和 Hibernate，希望寻找一款专为 Kotlin 开发的 ORM 框架。而 Ktorm 就是一款专门为 Kotlin 设计，旨在让数据库操作更加流畅、自然，更贴合 Kotlin 语法特性的 ORM 框架。

在这场分享里，将跟大家介绍 Ktorm 的核心设计、框架使用和扩展，并通过使用 Ktorm 写出更具 Kotlin 风味的数据库操作代码。听完这场分享后，将会对如何善用 Kotlin 语法来设计 ORM 框架有进一步的认识。

PPT 下载链接：ktorm-in-kotlin-conf-cn-2024.pdf

Gravatar 即全球通用头像 (Globally Recognized Avatar) 服务，用户只要在上面上传了自己的头像，那么在所有支持的网站上发帖时，只要提供与这个头像关联的 Email，就可以显示出自己的 Gravatar 头像。可以说是「一次上传，全网通用」~~

可惜国内的网络环境实在一言难尽，Gravatar 常年都处于无法访问的状态，所以本站一直都是用 v2ex 提供的 CDN 镜像，然而，就在前两周，v2ex 也被墙了，emm… 因为不想再白嫖其他的国内镜像，因此开始考虑自己动手搭建。这个事情其实挺简单的，网上随便搜索一下就有答案，只要有一台墙外的 VPS，用 nginx 给 Gravatar 做个反向代理就好。

但是，如果你的主机在墙内呢，怎么办？

科学上网

无论如何，科学上网是第一件必须解决的事情。如果你的主机甚至都不能访问 Gravatar，反向代理根本就无从谈起。要实现科学上网，你首先需要在墙外有可用的 Shadowsocks 服务用于代理你的流量，至于是使用 VPS 自建也好、直接购买机场的服务也好，这里不作探讨。

安装 Shadowsocks：

1
2

apt-get install python-pip
pip install shadowsocks

在 /etc/shadowsocks/config.json 目录创建一个配置文件：

1
2
3
4
5
6
7
8
9
10

{
  "server": "server_ip",         // 服务器地址
  "server_port": 8388,           // 服务器端口
  "local_address": "127.0.0.1",  // 本地 socks5 服务的监听地址
  "local_port": 1080,            // 本地 socks5 服务的监听端口
  "password": "password",        // 服务器密码
  "timeout": 300,                // 超时时间
  "method": "aes-256-gcm",       // 服务器加密方式
  "fast_open": false
}

配置完成后，使用 sslocal 命令启动客户端服务：

1

sslocal -c /etc/shadowsocks/config.json -d start

这个命令会在本地 1080 端口启动一个 socks5 代理，连接远程的 Shadowsocks 服务，把网络请求转发过去。

接下来检查一下这个代理是否可用，使用 curl 命令查询一下自己的 IP，--socks5-hostname 参数指定 socks5 代理服务的地址：

1
2
3
4
5
6
7
8
9
10

$ curl --socks5-hostname 127.0.0.1:1080 cip.cc
IP      : 104.xxx.xxx.xxx
地址    : 美国  加利福尼亚州  洛杉矶
运营商  : it7.net

数据二  : 美国 | 加利福尼亚州洛杉矶IT7网络

数据三  : 美国加利福尼亚

URL     : http://www.cip.cc/104.xxx.xxx.xxx

可以看到，IP 地址是国外的，证明我们已经可以科学上网了。

启动 socat 转发

照理说，实现科学上网之后，直接在 nginx 配置反向代理就能完成我们的任务。但遗憾的是，nginx 本身并不支持使用系统代理，也不像 curl 那样提供了 --socks5-hostname 参数用于显式指定代理，因此我们只能另谋出路。

这时我想到了 socat，socat 是一个多功能网络工具，它可以在两个网络数据流之间建立通道，实现端口转发的功能，同时还支持代理。但可惜的是，socat 目前只支持 socks4，还不支持 socks5，所以还不能直接用。在 GitHub 搜索发现已经有大佬给 socat 打过补丁，使其支持 socks5，因此决定使用这个补丁版本试试。这里给出项目的地址，有兴趣可以去点个 star：https://github.com/runsisi/socat

要安装这个补丁版的 socat，我们就不能直接使用 yum 或者 apt-get，而是要下载源码自己编译：

1
2
3
4
5
6
7

apt-get install git curl autoconf yodl make
git clone --depth=1 https://github.com/runsisi/socat.git
cd socat
autoconf
./configure --prefix=/usr
make
make install

注意，上面的第一步首先安装了编译的过程中需要用到的其他工具，其中 yodl 在 CentOs 中可能无法使用 yum 安装，也可以考虑通过下载源码自行编译的方式解决，项目地址：https://gitlab.com/fbb-git/yodl

安装之后，启动 socat，监听 1081 端口，把流量转发给 Gravatar，当然，需要走代理：

1

socat -d -d TCP4-LISTEN:1081,reuseaddr,fork SOCKS5:127.0.0.1:www.gravatar.com:443,socks5port=1080

尝试访问一下 1081 端口，发现已经可以正常获取到头像数据了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

$ curl -v -k -H 'Host: www.gravatar.com' -o /dev/null https://127.0.0.1:1081/avatar/123
* About to connect() to 127.0.0.1 port 1081 (#0)
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 1081 (#0)
> GET /avatar/123 HTTP/1.1
> User-Agent: curl/7.29.0
> Accept: */*
> Host: www.gravatar.com
>
< HTTP/1.1 200 OK
< Server: nginx
< Date: Thu, 22 Apr 2021 16:37:41 GMT
< Content-Type: image/jpeg
< Content-Length: 2637
< Connection: keep-alive
< Last-Modified: Wed, 11 Jan 1984 08:00:00 GMT
< Link: <https://www.gravatar.com/avatar/123>; rel="canonical"
< Access-Control-Allow-Origin: *
< Content-Disposition: inline; filename="123.jpg"
< Expires: Thu, 22 Apr 2021 16:42:41 GMT
< Cache-Control: max-age=300
< X-nc: HIT bur 3
< Accept-Ranges: bytes
<
{ [data not shown]
100  2637  100  2637    0     0   1172      0  0:00:02  0:00:02 --:--:--  1173
* Connection #0 to host 127.0.0.1 left intact

配置 nginx 反向代理

有了前面的准备工作之后，我们终于可以在 nginx 配置反向代理了，不过这里要注意的是，不能直接把流量转发给 Gravatar，而是转发给刚刚使用 socat 开启的本地 1081 端口。同时，为了减少回源的次数，提高访问速度，我们还可以做一层 proxy_cache 缓存。具体配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

http {
  proxy_cache_path  /var/cache/nginx levels=1:2 keys_zone=gravatar:8m max_size=10000m inactive=600m;
  proxy_temp_path   /var/cache/nginx/temp;

  server {
    listen          443;
    server_name     www.liuwj.me;
    ssl             on;

    location / {
      root          /var/www/www.liuwj.me;
    }
    location /gravatar/ {
      proxy_pass         https://localhost:1081/avatar/;
      proxy_set_header   Host www.gravatar.com;
      proxy_cache        gravatar;
      proxy_cache_valid  200 301 302 7d;
      proxy_cache_valid  404 502 1m;
      expires            7d;
    }
  }
}

配置完成后，尝试使用浏览器打开一个头像链接，确认是否能正常访问：https://www.liuwj.me/gravatar/123

大功告成！！一个头像请求，从浏览器发出之后，经过的路径应该是这样子的：

1
2
3

+---------+      +-------+      +-------+      +---------+      +----------+      +----------+
| browser | ---> | nginx | ---> | socat | ---> | sslocal | ---> | ssserver | ---> | gravatar |
+---------+      +-------+      +-------+      +---------+      +----------+      +----------+

可以说是十分曲折了…

本文转自 https://skyblond.info/archives/751.html

最近从滴滴辞职，为期 5 天的暑假正式开始了，寻思着做一点有意义的事情提升一下自己。遂决定自己写一套专门用于复杂查询的通联日志管理系统，数据库选用了 PostgreSQL，该数据库可以直接对 Json 类型的数据进行高级查询，然而 Ktorm 框架并不支持此功能，因此本文将记述为该框架进行拓展的过程。

需求

假设数据库中有一表 qso_infos 用于存储通联日志，其中 qsl_info 字段表示 QSL 相关事宜的记录，该字段为 jsonb 类型，样例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

{
    "lotw": {
        "uploaded": true,
        "uploadDate": "2020-06-20",
        "comfirmed": true,
        "comfireDate": "2020-07-21"
    },
    "card": {
        "sent": {
            "sent": false,
            "required": true,
            "sentDate": null,
            "requiredDate": "2020-06-21",
            "via": "bureau"
        },
        "received": {
            "received": false,
            "required": true,
            "receivedDate": null,
            "requiredDate": "2020-06-22",
            "via": "direct"
        }
    },
    "comment": "因为COVID-19推迟寄送QSL卡片"
}

现在需要查询所有 LoTW 未上传的记录，应当如何利用 Ktorm 在数据库端完成？

如果需要查询所有 comment 为空的记录，应当如何利用 Ktorm 在数据库端完成？

分析

如果直接编写 SQL 的话，应当按如下编写：

1
2

SELECT * FROM qso_infos WHERE qsl_info->'lotw'->>'uploaded' = 'false';
SELECT * FROM qso_infos WHERE qsl_info->>'comment' = '';

其中第一句还可以这样写：

1

SELECT * FROM qso_infos WHERE (qsl_info->>'lotw')::json->>'uploaded' = 'false';

第一种写法用到了两个不同的运算符：-> 是作为 Json 取出，而 ->> 则是作为字符串取出。需要注意的是对于 Json Object 这两个运算符是根据输入的字符串作为键去取值，而对于 Json Array 则是按照输入的整形作为从 0 开始的索引去取值。为了最大兼容性的考虑，本文将同时实现每个运算符的两个形式。

对于第二种写法，虽然只需要自定义一个运算符即可，但还需要将转换为 Json 作为一个额外的运算符实现。本文也将实现该运算符。

实现

SQL 类型扩展

为了实现对 Json 的访问，首先应当定义 json 和 jsonb 两个 SQL 数据类型。这里我没有使用 ktorm 的模块，而是基于 Gson 写了一个：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

package info.skyblond.jinn.extension

import com.google.gson.Gson
import org.ktorm.schema.BaseTable
import org.ktorm.schema.Column
import org.ktorm.schema.SqlType
import org.ktorm.schema.TypeReference
import java.lang.reflect.Type
import java.sql.PreparedStatement
import java.sql.ResultSet
import java.sql.Types

class JsonbSqlType<T : Any>(private val type: Type) : SqlType<T>(Types.JAVA_OBJECT, typeName = "jsonb") {
    private val gson = Gson()

    override fun doSetParameter(ps: PreparedStatement, index: Int, parameter: T) {
        ps.setString(index, gson.toJson(parameter))
    }

    override fun doGetResult(rs: ResultSet, index: Int): T? {
        val json = rs.getString(index)
        return if (json.isNullOrBlank()) {
            null
        } else {
            gson.fromJson(json, type)
        }
    }
}

fun <C : Any> BaseTable<*>.jsonb(
    name: String,
    typeReference: TypeReference<C>
): Column<C> {
    return registerColumn(name, JsonbSqlType(typeReference.referencedType))
}

internal class JsonSqlType<T : Any>(private val type: Type) : SqlType<T>(Types.JAVA_OBJECT, typeName = "json") {
    private val gson = Gson()

    override fun doSetParameter(ps: PreparedStatement, index: Int, parameter: T) {
        ps.setString(index, gson.toJson(parameter))
    }

    override fun doGetResult(rs: ResultSet, index: Int): T? {
        val json = rs.getString(index)
        return if (json.isNullOrBlank()) {
            null
        } else {
            gson.fromJson(json, type)
        }
    }
}

fun <C : Any> BaseTable<*>.json(
    name: String,
    typeReference: TypeReference<C>
): Column<C> {
    return registerColumn(name, JsonSqlType(typeReference.referencedType))
}

关于代码就不多说了，具体可以参考 Ktorm 文档 - 定义表结构 - 扩展更多的类型。这里最重要的一点就是要使用限制比较宽松的框架进行 Json 转换，一开始我试图使用 kotlinx 的 serialization 进行，于是进行 Json 转换的时候就需要一个 KSerializer 对象才能工作，而该对象的获取渠道是 SomeClass.serializer()，其中 SomeClass 需要被 @kotlinx.serialization.Serializable 注解。之后进行 Json 操作时为了最大的兼容性，通常都是认为操作的结果是 Any 而非特定一个类，那么问题就来了：Any 类似 Java 的 Object，是万物之父，而所有被 @Serializable 注解的类，可没有一个统一的父类。因此这样的架构在后续实现运算符的时候就会非常难受。最起码也是要实现了 Java 的 Serializable 接口（或其他框架的统一的接口）。

现在有了 Json 数据类型，接下来我们就可以实现运算符了。

自定义运算符

关于自定义运算符，这里同样不多赘述，详细指导可以参考 Ktorm 文档 - 运算符 - 自定义运算符。拓展的代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

package info.skyblond.jinn.extension

import org.ktorm.expression.ArgumentExpression
import org.ktorm.expression.ScalarExpression
import org.ktorm.schema.ColumnDeclaring
import org.ktorm.schema.IntSqlType
import org.ktorm.schema.SqlType
import org.ktorm.schema.VarcharSqlType

data class AsJsonExpression(
    val left: ScalarExpression<*>,
    override val sqlType: SqlType<Any> = JsonSqlType(Any::class.java),
    override val isLeafNode: Boolean = false,
    override val extraProperties: Map<String, Any> = mapOf(),
    val alreadyJson: Boolean = false
) : ScalarExpression<Any>()

/**
 * This function make a AsJsonExpression.
 * When alreadyJson is true, the expression does nothing, just to make compiler happy.
 */
fun ColumnDeclaring<*>.asJson(alreadyJson: Boolean = false): AsJsonExpression {
    return AsJsonExpression(asExpression(), alreadyJson = alreadyJson)
}

// Get as Json

data class JsonAccessExpression<T : Any>(
    val left: AsJsonExpression,
    val right: ArgumentExpression<T>,
    override val sqlType: SqlType<Any> = JsonSqlType(Any::class.java),
    override val isLeafNode: Boolean = false,
    override val extraProperties: Map<String, Any> = mapOf()
) : ScalarExpression<Any>()

operator fun AsJsonExpression.get(param: String): AsJsonExpression {
    return JsonAccessExpression(this, ArgumentExpression(param, VarcharSqlType)).asJson(true)
}

operator fun AsJsonExpression.get(param: Int): AsJsonExpression {
    return JsonAccessExpression(this, ArgumentExpression(param, IntSqlType)).asJson(true)
}

// Get as Text

data class JsonAccessAsTextExpression<T : Any>(
    val left: AsJsonExpression,
    val right: ArgumentExpression<T>,
    override val sqlType: SqlType<String> = VarcharSqlType,
    override val isLeafNode: Boolean = false,
    override val extraProperties: Map<String, Any> = mapOf()
) : ScalarExpression<String>()

fun AsJsonExpression.getAsString(param: String): JsonAccessAsTextExpression<String> {
    return JsonAccessAsTextExpression(this, ArgumentExpression(param, VarcharSqlType))
}

fun AsJsonExpression.getAsString(param: Int): JsonAccessAsTextExpression<Int> {
    return JsonAccessAsTextExpression(this, ArgumentExpression(param, IntSqlType))
}

在这里我们实现了 AsJsonExpression，该表达式将前面的语句转换成 Json 类型；JsonAccessExpression，该表达式将对 Json 类型的数据进行 -> 运算；JsonAccessAsTextExpression，该表达式将对 Json 类型的数据进行 ->> 运算。

在 Ktorm 中对于数据的面向对象式筛选，实际上是基于面向对象的写法产生一个表达式树。该树中的每一个 Expression 表示一个运算或参数，最终将被解析为一条 SQL 语句。

值得注意的是在 AsJsonExpression 的实现中只有 left，原本是打算将其作为 AsDataTypeExpression，然后 right 作为一个 SqlType 来实现更通用的功能的，但是这样一来后面的实现将无法保证只对 Json 类型的语句进行访问：JsonSqlType 要能够适配所有情况，其类型必定是 SqlType，这样一来将无法区分哪些表达式是 Json，哪些不是。当然你也可以额外在加一个类型：AsDataTypeExpression，T 作为 SqlType，而 U 直接存储 JsonSqlType，但是就本文而言，还是单独搞一个 AsJsonExpression 来的最实在。

关于 asJson() 函数，设置 alreadyJson 的目的就是后面对于 -> 运算符，其运算结果本身就是 Json，而对于编译器来说则是 JsonAccessExpression 类型，不能应用 AsJsonExpression 的访问操作。因此这里只是单纯的为了让编译器开心，当进行 -> 访问时，除了产生一个访问表达式之外，还在外面报一个 AsJsonExpression，这样对于编译器来说就是合法的 Json 类型了，而在生成 SQL 语句时通过判断 alreadyJson 字段可以跳过本次类型转换。

最后为了写起来更舒爽，对于作为 Json Object 取出的 -> 运算，我重载了 kotlin 内置的 get 方法，这样就可以通过 asJson()[keyName] 的形式进行访问了。

而只进行到此还是不够全面，目前 ktorm 还不能正确翻译这些表达式。下一步将进行方言扩展。

扩展方言

既然说扩展方言，就是说我们并不像替代原有的 PostgreSQL 方言，而 Ktorm 的作者也贴心的将方言实现类加了 open 关键字，这样我们就可以自由的进行扩展了。根据 Ktorm 文档 - 运算符 - 自定义运算符，扩展的方言应当覆盖对未知表达式的处理：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

package info.skyblond.jinn.extension

import org.ktorm.database.Database
import org.ktorm.expression.SqlExpression
import org.ktorm.expression.SqlFormatter
import org.ktorm.support.postgresql.PostgreSqlDialect
import org.ktorm.support.postgresql.PostgreSqlFormatter

open class MyPostgreSqlDialect : PostgreSqlDialect() {

    override fun createSqlFormatter(database: Database, beautifySql: Boolean, indentSize: Int): SqlFormatter {
        return MyPostgreSqlFormatter(database, beautifySql, indentSize)
    }
}

class MyPostgreSqlFormatter(database: Database, beautifySql: Boolean, indentSize: Int)
    : PostgreSqlFormatter(database, beautifySql, indentSize) {

    override fun visitUnknown(expr: SqlExpression): SqlExpression {
        return when (expr) {
            is AsJsonExpression -> {
                if (expr.left.removeBrackets) {
                    visit(expr.left)
                } else {
                    write("(")
                    visit(expr.left)
                    removeLastBlank()
                    write(") ")
                }

                // if already json, then do nothing, just make compiler happy
                if (!expr.alreadyJson) {
                    removeLastBlank()
                    write("::json ")
                }
                expr
            }
            is JsonAccessAsTextExpression<*> -> {
                // Json only, no need to add brackets
                visit(expr.left)

                write("->> ")

                visit(expr.right)

                expr
            }
            is JsonAccessExpression<*> -> {
                // Json only, no need to add brackets
                visit(expr.left)

                write("-> ")

                visit(expr.right)

                expr
            }
            else -> {
                super.visitUnknown(expr)
            }
        }
    }
}

在遇到没有见过的表达式时，将回调父类的处理函数，而这个函数的默认行为就是抛异常。这里在产生 SQL 语句的时候有一些细节要注意。

对于转换为 Json 的语句，需要时应当增加括号来保证运算优先级的正确性。而对于 Json 的访问，其左值一定是 Json，而右值则一定是数字或字符串类型的参数，因此左右皆无需增加括号。

最后我们需要在连接数据库的时候指定该方言。

结果

首先连接数据库：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

val pgDataSource = PGDataSource()
pgDataSource.serverName = "localhost"
pgDataSource.portNumber = 5432
pgDataSource.user = "logbook"
pgDataSource.password = "***"
pgDataSource.databaseName = "logbook"

val config = HikariConfig()
config.driverClassName = "com.impossibl.postgres.jdbc.PGDataSource"
config.dataSource = pgDataSource
config.addDataSourceProperty("cachePrepStmts", "true")
config.addDataSourceProperty("prepStmtCacheSize", "250")
config.addDataSourceProperty("prepStmtCacheSqlLimit", "2048")

val hikariDataSource = HikariDataSource(config)

val database = Database.connect(hikariDataSource, dialect = MyPostgreSqlDialect())

注意最后在连接数据库的时候指定了我们自己实现的方言。之后在定义完表和实体类之后进行查询：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

database.sequenceOf(QsoInfos).filter {
    it.qslInfo.asJson(true)["lotw"].getAsString("uploaded") eq "true"
}.forEach {
    println(it)
}

database.sequenceOf(QsoInfos).filter {
    it.qslInfo.asJson(true)["card"]["sent"].getAsString("sent") eq "false"
}.forEach {
    println(it)
}

database.sequenceOf(QsoInfos).filter {
    it.qslInfo.asJson(true).getAsString("comment") notEq ""
}.forEach {
    println(it)
}

database.sequenceOf(QsoInfos).filter {
    it.qslInfo.asJson(true).getAsString("card").asJson().getAsString("sent").asJson().getAsString("sent") notEq "true"
}.forEach {
    println(it)
}

对应的分别产生了如下 SQL：

1
2
3
4
5
6
7
8
9
10
11

DEBUG org.ktorm.database - SQL: select ... from qso_infos where ((qso_infos.qsl_info -> ?) ->> ?) = ? 
DEBUG org.ktorm.database - Parameters: [lotw(varchar), uploaded(varchar), true(varchar)]

DEBUG org.ktorm.database - SQL: select ... from qso_infos where (((qso_infos.qsl_info -> ?) -> ?) ->> ?) = ? 
DEBUG org.ktorm.database - Parameters: [card(varchar), sent(varchar), sent(varchar), false(varchar)]

DEBUG org.ktorm.database - SQL: select ... from qso_infos where (qso_infos.qsl_info ->> ?) <> ? 
DEBUG org.ktorm.database - Parameters: [comment(varchar), (varchar)]

DEBUG org.ktorm.database - SQL: select ... from qso_infos where (((qso_infos.qsl_info ->> ?)::json ->> ?)::json ->> ?) <> ? 
DEBUG org.ktorm.database - Parameters: [card(varchar), sent(varchar), sent(varchar), true(varchar)]

看起来符合预期，程序也没有报错。至此可以算是完美决绝问题。

- 全文完 -

但是当我打开这个类的时候，看到的除了字段定义以外还有一大堆使用 idea 生成的 getter/setter 方法。甚至这些 getter/setter 方法占用的代码行数反而更多，严重干扰视线，阅读代码体验极差。

这时我就产生了重构的想法，思路是删掉这些没必要的 getter/setter 方法，改用 lombok 的 @Data 注解代替。因为 lombok 本来在项目中就有使用，所以应该不会有什么问题。改完之后，我测试了我正在做的这个功能，一切正常，代码部署到测试环境之后也运行良好。

但是万万没有想到，问题竟然出现在与这个功能看起来毫不相关的另一个模块。这个模块启动后抛出了一个 NoSuchMethodError：

抛异常的地方确实是我改过的 Banner 类，但是 lombok 应该会为我们生成相应的 getter/setter 方法，所以这里不应该找不到才对，难道是 lombok 抽风了？

查找原因的时候，有的同事认为原因是我把 lombok 的依赖设置成 optional，导致运行的时候没有 lombok 的 jar 才出现这个异常。然而这种理解是错误的，因为 lombok 生成代码的原理是通过 javac 提供的 APT（Annotation Processing Tool，注解处理器）机制在编译过程中对 Java 代码的 AST 进行修改，这一切都发生在编译时，因此在运行时并不需要 lombok 的存在。换句话说，如果是因为 lombok 导致的问题，不会等到运行的时候才抛出异常，而是在编译的时候就崩了。

真正的原因比较隐蔽，仔细寻找之后才能发现。在我修改前的 Banner 类中，有一个 id 字段，它的定义是这样的：

1

private Long id;

可以看到，这里使用的是包装类型的 Long，但是它的 getter/setter 方法使用的却是基本类型的 long：

1
2
3
4
5
6
7

public long getId() {
    return id;
}

public void setId(long id) {
    this.id = id;
}

严格来说，这样根本不符合 Java Bean 的规范，使用 idea 也不可能会生成这样的 getter/setter 方法，所以我猜测原代码的作者应该是先使用 idea 生成了代码，然后手动修改了里面的类型。

当我把这两个方法删掉，加上 lombok 的 @Data 注解之后，lombok 给我们生成的的 getter/setter 方法的类型会与字段的类型相同，即 Long getId()。

理论上，当方法的签名从 long getId() 变成 Long getId() 之后，代码是不会报错的，因为就算原来有地方使用了 long 来接收返回值，我们的方法签名改成 Long 之后返回的包装类型也会被自动拆箱。然而正因为它不会报错，才让我没有立即发现问题。

当我们讨论一段被修改的代码的兼容性的时候，我们其实隐含了两层完全不一样的意思。兼容性分为两个层次：

• 源码级兼容：当我们修改了一段代码，依赖它的其他代码在编译时不需要修改即可直接通过，此为源码级兼容。
• 二进制级兼容：比源码级兼容更进一层，当我们修改了一段代码，依赖它的其他代码不需要修改，甚至也不需要重新编译也可运行正常。

一般来说，我们平时写代码只需要做到源码级兼容即可，二进制级兼容只在很少情况下才会需要。

在这个例子中，我们的方法签名在无意间从 long getId() 变成了 Long getId()，这在源码层面是兼容的，所以编译的时候不会报错。但是在 Java 字节码中，long getId() 和 Long getId() 是两个完全不一样的方法，因此这个修改是二进制不兼容的。

我的项目的模块依赖是这样的：

Banner.java 在模块 C 中，我修改之后 deploy 了一个新版本到 maven 仓库，因此其他模块可以下载到它。

模块 B 依赖了模块 C，并且在里面使用了 Banner 类的 long getId() 方法，这正是发生这次错误的原因。

模块 A 同时依赖了模块 B 和模块 C。因为我修改过模块 C，并且 deploy 了一个新版本，因此在构建的时候会下载这个最新的 jar 包，但是我并没有修改过模块 B，所以模块 A 在构建的时候使用的仍然是旧的 jar 包。这个旧的 jar 包在运行的时候会尝试去调用签名为 long getId() 的方法，但是这个方法的签名已经被我在无意间改成了 Long getId()，因此才会发生找不到方法的异常。

找到异常的原因之后，解决方法很自然就有了，那就是重新编译模块 B，并把它 deploy 到 maven 仓库中即可。

这次的问题是一个说明代码兼容性的不同层次的一个很好的例子，这种问题排查起来虽然不算太难，但是发生的原因十分隐蔽，也足够我们折腾一会。为了避免大家以后踩到和我类似的坑，在这里我把整个过程记录下来，然后给出一点不成熟的小建议：

• 面向甩锅编程，如非必要，坚决不要修改除自己需求以外的任何一行代码，更不要幻想重构，否则出了事情可能会背锅
• 字段的 getter/setter 方法要符合 Java Bean 的通用规范，否则其他同学在阅读或修改代码的时候容易忽略掉一些细微之处，某些框架也可能会因为这个产生一些奇怪的 bug。
• 为保证 getter/setter 方法能严格符合规范，推荐尽量使用 lombok，不推荐使用 idea 的代码生成，多出来的代码会多出额外的维护成本。
• 就算使用 idea 来生成 getter/setter 方法，在生成后也请尽量不要去编辑，若以后字段的名字或类型有变化，可把原来的 getter/setter 方法删掉再重新生成一次。
• 如果这些模块属于同一个工程，建议使用 maven 父子工程来组织项目，这样在编译模块 A 的时候，也会同时编译它依赖的模块 B 和模块 C，可以很大程度避免此类问题。

当然，最好的方法还是赶紧换成 Kotlin (强行安利)，去 tm 的 getter/setter…

前文地址：你还在用 MyBatis 吗，Ktorm 了解一下？
Ktorm 官网：https://www.ktorm.org

在开始之前，我们先回顾一下上篇文章中的员工-部门表的例子，这次我们的示例也是基于这两个表。下面是使用 Ktorm 定义的这两个表的结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

object Departments : Table<Nothing>("t_department") {
    val id = int("id").primaryKey()    // Column<Int>
    val name = varchar("name")         // Column<String>
    val location = varchar("location") // Column<String>
}

object Employees : Table<Nothing>("t_employee") {
    val id = int("id").primaryKey()
    val name = varchar("name")
    val job = varchar("job")
    val managerId = int("manager_id")
    val hireDate = date("hire_date")
    val salary = long("salary")
    val departmentId = int("department_id")
}

在上面的表定义中，我们可以看到，Ktorm 一般使用 Kotlin 中的 object 关键字定义一个继承 Table 类的对象来描述表结构。这里的 Departments 和 Employees 都继承了 Table，并且在构造函数中指定了表名。表中的列使用 val 关键字定义为表对象中的成员属性，列的类型通过 int、long、varchar、date 等函数定义，它们分别对应了 SQL 中的相应类型。

在 Ktorm 中，int、long、varchar、date 这类函数称为列定义函数，它们的功能是在当前表中增加一条指定名称和类型的列。Ktorm 内置了许多列定义函数，它们基本涵盖了关系数据库所支持的大部分数据类型。但是，在某些情况下，我们需要在数据库中保存一些原生 JDBC 所不支持的特殊类型的数据（比如 json），这就要求框架能给我们提供扩展数据类型的方式。

使用扩展函数支持更多数据类型

SqlType 是 Ktorm 中的一个抽象类，它为 SQL 中的数据类型提供了统一的抽象，要扩展自己的数据类型，我们首先需要提供一个自己的 SqlType 实现类。下面的 JsonSqlType 使用 Jackson 框架进行 json 与对象之间的转换，提供了 json 数据类型的支持：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class JsonSqlType<T : Any>(
    val objectMapper: ObjectMapper,
    val javaType: JavaType
) : SqlType<T>(Types.VARCHAR, "json") {

    override fun doSetParameter(ps: PreparedStatement, index: Int, parameter: T) {
        ps.setString(index, objectMapper.writeValueAsString(parameter))
    }

    override fun doGetResult(rs: ResultSet, index: Int): T? {
        val json = rs.getString(index)
        if (json.isNullOrBlank()) {
            return null
        } else {
            return objectMapper.readValue(json, javaType)
        }
    }
}

有了 JsonSqlType 之后，接下来的问题就是如何在表对象中添加一条 json 类型的列。我们已经知道，int、varchar 等内置列定义函数的功能正是在当前表对象中注册一条相应类型的列，那么我们能不能自己写一个列定义函数呢？

如果我们用的是 Java，这时恐怕只能遗憾地放弃了，但是 Kotlin 不一样，它支持扩展函数！Kotlin 的扩展函数可以让我们方便地扩展一个已经存在的类，为它添加额外的函数。

1
2
3
4
5
6

inline fun <reified C : Any> BaseTable<*>.json(
    name: String,
    mapper: ObjectMapper = sharedObjectMapper
): Column<C> {
    return registerColumn(name, JsonSqlType(mapper, mapper.constructType(typeOf<C>())))
}

使用上面这个扩展函数，我们可以很方便地在当前表对象中添加一条 json 类型的列，它的用法和 Ktorm 内置的列定义函数没有任何区别。

1
2
3

object Employees : Table<Nothing>("t_employee") {
    val hobbies = json<List<String>>("hobbies")
}

扩展函数是 Kotlin 的一项重要特性，可以让我们在不修改一个类的情况下，为它添加额外的属性和函数，这极大地提高了我们编程的灵活性。Ktorm 对扩展函数有许多的应用，它的绝大部分 API 都是通过扩展函数的方式来提供的。实际上，前面提到的 int、varchar 等内置列定义函数也都是通过扩展函数实现的。

使用 DSL 编写 SQL

DSL（Domain Specific Language，领域特定语言）是专为解决某一特定问题而设计的语言。与通用编程语言相比，DSL 更趋向于声明式，能够更加简洁地表达特定领域的操作。Kotlin 为我们提供了构建内部 DSL 的强大能力，所谓内部 DSL，即使用 Kotlin 语言开发的，解决特定领域问题，具备独特代码结构的 API。

在代码中拼接 SQL 字符串一直是各位程序员心中的痛，Ktorm 提供了强类型的 DSL，让我们可以使用更安全和简便的方式编写 SQL。下面是一个使用 DSL 的例子，它查询每个部门的员工数量，并把部门按人数从高到低排序：

1
2
3
4
5
6
7
8
9

database
    .from(Departments)
    .innerJoin(Employees, on = Departments.id eq Employees.departmentId)
    .select(Departments.name, count(Employees.id))
    .groupBy(Departments.name)
    .orderBy(count(Employees.id).desc())
    .forEach { row ->
        println("Dept Name: ${row.getString(1)}, Emp Count: ${row.getInt(2)}")
    }

当你运行这段代码，Ktorm 会自动执行一条 SQL，生成的 SQL 如下：

1
2
3
4
5

select t_department.name as t_department_name, count(t_employee.id) 
from t_department 
inner join t_employee on t_department.id = t_employee.department_id 
group by t_department.name 
order by count(t_employee.id) desc 

这就是 Kotlin 的魔法，使用 Ktorm 写查询十分地简单和自然，所生成的 SQL 几乎和 Kotlin 代码一一对应。并且，Ktorm 是强类型的，编译器会在你的代码运行之前对它进行检查，IDE 也能对你的代码进行智能提示和自动补全。

除了查询以外，Ktorm 的 DSL 还支持插入和修改数据，比如向表中插入一名新员工：

1
2
3
4
5
6
7
8

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

生成 SQL：

1
2

insert into t_employee (name, job, manager_id, hire_date, salary, department_id) 
values (?, ?, ?, ?, ?, ?) 

给名为 vince 的员工加一个小目标的薪水：

1
2
3
4
5
6

database.update(Employees) {
    set(it.salary, it.salary + 100000000)
    where {
        it.name eq "vince"
    }
}

生成 SQL：

1

update t_employee set salary = salary + ? where name = ? 

运算符重载

在前面给 vince 加薪的过程中，细心的同学可能会发现我们很自然地使用了一个加号：it.salary + 100000000。然而，Employees.salary 的类型是 Column<Long>，我们怎么能把它和一个数字相加呢。这是因为 Kotlin 允许我们对运算符进行重载，使用 operator 关键字修饰的名为 plus 的函数定义了一个加号运算符。当我们对一个 Column 使用加号时，Kotlin 实际上调用了 Ktorm 中的这个 plus 函数：

1
2
3
4
5
6
7
8

operator fun <T : Number> Column<T>.plus(argument: T): BinaryExpression<T> {
    return BinaryExpression(
        type = BinaryExpressionType.PLUS, 
        left = this.asExpression(), 
        right = this.wrapArgument(argument), 
        sqlType = this.sqlType
    )
}

上面的函数重载了加号运算符，但它并没有真正执行加法运算，它只是返回了一个 SQL 表达式，这个表达式最终会被 SqlFormatter 翻译为 SQL 中的加号。通过这种方式，Ktorm 得以将 Kotlin 中的四则运算符翻译为 SQL 中的相应符号。

除了加号以外，Ktorm 还重载了许多常用的运算符，它们包括加号、减号、一元加号、一元减号、乘号、除号、取余、取反等。下面的例子使用取余符号 % 查询数据库中 ID 为奇数的员工：

1

val query = database.from(Employees).select().where { Employees.id % 2 eq 1 }

生成 SQL：

1

select * from t_employee where (t_employee.id % ?) = ? 

通过 infix 定义自己的运算符

通过运算符重载，Ktorm 能够将 Kotlin 中四则运算符翻译为 SQL 中的相应符号。但是 Kotlin 的运算符重载还有许多的限制，比如：

• 判等运算符（equals 方法）的返回值类型必须是 Boolean。然而，为了将 Kotlin 中的运算符翻译到 SQL，Ktorm 要求运算符函数必须返回一个 SqlExpression，以记录我们的表达式的语法结构（比如上文中的 plus 函数）。
• 支持的运算符有限，无法支持 SQL 中的特殊运算符，比如 like。

天无绝人之路，Kotlin 提供了 infix 修饰符，使用 infix 修饰的函数，在调用时可以省略点和括号，这为我们开启了另一个思路。比如，使用 infix 关键字修饰 eq 函数，用来支持判等操作，这个 eq 函数我们再前面已经用过许多次：

1
2
3
4
5
6
7
8

infix fun <T : Any> Column<T>.eq(expr: Column<T>): BinaryExpression<Boolean> {
    return BinaryExpression(
        type = BinaryExpressionType.EQUAL, 
        left = this.asExpression(), 
        right = expr.asExpression(), 
        sqlType = BooleanSqlType
    )
}

除了 eq 函数外，Ktorm 还提供了许多常用的运算符函数，它们包括 and、or、gt、lt、like 等。不仅如此，我们还能通过 infix 关键字定义自己特殊的运算符，比如 PostgreSQL 中的 ilike 运算符就可以定义为这样的一个 infix 函数：

1
2
3

infix fun Column<*>.ilike(argument: String): ILikeExpression {
    return ILikeExpression(asExpression(), ArgumentExpression(argument, VarcharSqlType)
}

有了这个 ilike 函数，接下来就只需要在 SqlFormatter 中把这个 ILikeExpression 翻译为合适的 SQL 就可以了，Ktorm 给我们提供了足够的灵活性，具体可以参考自定义运算符相关的文档。

Sequence API 像集合一样操作数据库

除了 SQL DSL 以外，Ktorm 还提供了一套名为“实体序列”的 API，用来从数据库中获取实体对象。正如其名字所示，它的风格和使用方式与 Kotlin 标准库中的序列 API 及其类似，它提供了许多同名的扩展函数，比如 filter、map、reduce 等。

要使用实体序列 API，我们首先要定义实体类，并把表对象与实体类进行绑定：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

interface Employee : Entity<Employee> {
    val id: Int?
    var name: String
    var job: String
    var manager: Employee?
    var hireDate: LocalDate
    var salary: Long
    var department: Department
}

object Employees : Table<Employee>("t_employee") {
    val id = int("id").primaryKey().bindTo { it.id }
    val name = varchar("name").bindTo { it.name }
    val job = varchar("job").bindTo { it.job }
    val managerId = int("manager_id").bindTo { it.manager.id }
    val hireDate = date("hire_date").bindTo { it.hireDate }
    val salary = long("salary").bindTo { it.salary }
    val departmentId = int("department_id").references(Departments) { it.department }
}

val Database.employees get() = this.sequenceOf(Employees)

完成 ORM 绑定后，我们就可以使用实体序列的各种方便的扩展函数。比如获取部门 1 中工资超过一千的所有员工对象：

1
2
3
4

val employees = database.employees
    .filter { it.departmentId eq 1 }
    .filter { it.salary gt 1000 }
    .toList()

可以看到，实体序列的用法几乎与 kotlin.sequences.Sequence 完全一样，不同的仅仅是在 lambda 表达式中的等号 == 和大于号 > 被这里的 eq 和 gt 函数代替了而已。

我们还能使用 mapColumns 函数筛选需要的列，而不必把所有的列都查询出来，以及使用 sortedBy 函数把记录按指定的列进行排序。下面的代码获取部门 1 中工资超过一千的所有员工的名字，并按其工资的高低从大到小排序：

1
2
3
4
5

val names = database.employees
    .filter { it.departmentId eq 1 }
    .filter { it.salary gt 1000L }
    .sortedBy { it.salary }
    .mapColumns { it.name }

生成的 SQL 正如我们所料：

1
2
3
4
5

select t_employee.name 
from t_employee 
left join t_department _ref0 on t_employee.department_id = _ref0.id 
where (t_employee.department_id = ?) and (t_employee.salary > ?) 
order by t_employee.salary 

不仅如此，我们还能使用聚合功能，获取每个部门的平均工资：

1
2
3

val averageSalaries = database.employees
    .groupingBy { it.departmentId }
    .eachAverageBy { it.salary }

生成 SQL：

1
2
3

select t_employee.department_id, avg(t_employee.salary) 
from t_employee 
group by t_employee.department_id 

使用 Ktorm 的实体序列 API，可以让我们的数据库操作看起来就像在使用 Kotlin 中的集合一样。值得注意的是，实体序列 API 并没有真正实现 Kotlin 中的 Sequence 接口，Ktorm 只不过是设计了一套与其命名相似函数，以降低用户学习的成本，同时提供与 Kotlin 集合操作体验一致的编码风格。

小结

在本文中，我们结合 Kotlin 的一些语法特性，探索了 Ktorm 框架中的许多设计细节。我们学习了如何使用扩展函数为 Ktorm 增加更多数据类型的支持、如何使用强类型的 DSL 编写 SQL、如何使用运算符重载和 infix 关键字为 Ktorm 扩展更多的运算符、以及如何使用实体序列 API 像集合一样操作数据库等。通过对这些细节的探讨，我们看到了 Ktorm 是如何充分利用 Kotlin 的优秀语法特性，帮助我们写出更优雅的、更具 Kotlin 风味的数据库操作代码。

Enjoy Ktorm, enjoy Kotlin!

然而，切换到 Kotlin 之后，你还在用 MyBatis 吗？MyBatis 作为一个 Java 的 SQL 映射框架，虽然在国内使用人数众多，但是也受到了许多吐槽。使用 MyBatis，你必须要忍受在 XML 里写 SQL 这种奇怪的操作，以及在众多 XML 与 Java 接口文件之间跳来跳去的麻烦，以及往 XML 中传递多个参数时的一坨坨 @Param 注解(或者你使用 Map？那就更糟了，连基本的类型校验都没有，参数名也容易写错)。甚至，在与 Kotlin 共存的时候，还会出现一些奇怪的问题，比如： Kotlin 遇到 MyBatis：到底是 Int 的错，还是 data class 的错？。

这时，你可能想要一款专属于 Kotlin 的 ORM 框架。它可以充分利用 Kotlin 的各种优良特性，让我们写出更加 Kotlin 的代码。它应该是轻量级的，只需要添加依赖即可直接使用，不需要各种麻烦的配置文件。它的 SQL 最好可以自动生成，不需要像 MyBatis 那样每条 SQL 都自己写，但是也给我们保留精确控制 SQL 的能力，不至于像 Hibernate 那样难以进行 SQL 调优。

如果你真的这么想的话，Ktorm 可能会适合你。Ktorm 是直接基于纯 JDBC 编写的高效简洁的 Kotlin ORM 框架，它提供了强类型而且灵活的 SQL DSL 和方便的序列 API，以减少我们操作数据库的重复劳动。当然，所有的 SQL 都是自动生成的。本文的目的就是对 Ktorm 进行介绍，帮助我们快速上手使用。

你可以在 Ktorm 的官网上获取更详细的使用文档，如果使用遇到问题，还可以在 GitHub 提出 issue。如果 Ktorm 对你有帮助的话，请在 GitHub 留下你的 star，也欢迎加入我们，共同打造 Kotlin 优雅的 ORM 解决方案。

Ktorm 官网：https://www.ktorm.org
GitHub 地址：https://github.com/kotlin-orm/ktorm

Hello, Ktorm!

还记得我们刚开始学编程的时候写的第一个程序吗，现在我们先从 Ktorm 的 “Hello, World” 开始，了解如何快速地搭建一个使用 Ktorm 的项目。

Ktorm 已经发布到 maven 中央仓库和 jcenter，因此，如果你使用 maven 的话，首先需要在 pom.xml 文件里面添加一个依赖：

1
2
3
4
5

<dependency>
    <groupId>org.ktorm</groupId>
    <artifactId>ktorm-core</artifactId>
    <version>${ktorm.version}</version>
</dependency>

或者 gradle：

1

compile "org.ktorm:ktorm-core:${ktorm.version}"

在使用 Ktorm 之前，我们需要让它能够了解我们的表结构。假设我们有两个表，他们分别是部门表 t_department 和员工表 t_employee， 它们的建表 SQL 如下，我们要如何描述这两个表呢？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

create table t_department(
  id int not null primary key auto_increment,
  name varchar(128) not null,
  location varchar(128) not null
);

create table t_employee(
  id int not null primary key auto_increment,
  name varchar(128) not null,
  job varchar(128) not null,
  manager_id int null,
  hire_date date not null,
  salary bigint not null,
  department_id int not null
);

一般来说，Ktorm 使用 Kotlin 中的 object 关键字定义一个继承 Table 类的对象来描述表结构，上面例子中的两个表可以像这样在 Ktorm 中定义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

object Departments : Table<Nothing>("t_department") {
    val id = int("id").primaryKey()    // Column<Int>
    val name = varchar("name")         // Column<String>
    val location = varchar("location") // Column<String>
}

object Employees : Table<Nothing>("t_employee") {
    val id = int("id").primaryKey()
    val name = varchar("name")
    val job = varchar("job")
    val managerId = int("manager_id")
    val hireDate = date("hire_date")
    val salary = long("salary")
    val departmentId = int("department_id")
}

可以看到，Departments 和 Employees 都继承了 Table，并且在构造函数中指定了表名，Table 类还有一个泛型参数，它是此表绑定到的实体类的类型，在这里我们不需要绑定到任何实体类，因此指定为 Nothing 即可。表中的列则使用 val 关键字定义为表对象中的成员属性，列的类型使用 int、long、varchar、date 等函数定义，它们分别对应了 SQL 中的相应类型。

定义好表结构后，我们就可以使用 Database.connect 函数连接到数据库，然后执行一个简单的查询：

1
2
3
4
5
6
7

fun main() {
    val database = Database.connect("jdbc:mysql://localhost:3306/ktorm", user = "root", password = "***")

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

这就是一个最简单的 Ktorm 项目，这个 main 函数中只有短短三四行代码，但是你运行它时，它却可以连接到数据库，自动生成一条 SQL select * from t_employee，查询表中所有的员工记录，然后打印出他们的名字。因为 select 函数返回的查询对象重载了迭代运算符，所以你可以在这里使用 for-each 循环的语法。

SQL DSL

让我们在上面的查询里再增加一点筛选条件：

1
2
3
4
5
6
7

database
    .from(Employees)
    .select(Employees.name)
    .where { (Employees.departmentId eq 1) and (Employees.name like "%vince%") }
    .forEach { row -> 
        println(row[Employees.name])
    }

生成的 SQL 如下:

1
2
3

select t_employee.name as t_employee_name 
from t_employee 
where (t_employee.department_id = ?) and (t_employee.name like ?)

这就是 Kotlin 的魔法，使用 Ktorm 写查询十分地简单和自然，所生成的 SQL 几乎和 Kotlin 代码一一对应。并且，Ktorm 是强类型的，编译器会在你的代码运行之前对它进行检查，IDE 也能对你的代码进行智能提示和自动补全。

实现基于条件的动态查询也十分简单，因为都是纯 Kotlin 代码，直接使用 if 语句就好，比 MyBatis 在 XML 里面写 <if> 标签好太多。

1
2
3
4
5
6
7
8
9
10
11

val query = database
    .from(Employees)
    .select(Employees.name)
    .whereWithConditions {
        if (someCondition) {
            it += Employees.managerId.isNull()
        }
        if (otherCondition) {
            it += Employees.departmentId eq 1
        }
    }

聚合查询：

1
2
3
4
5
6
7
8
9

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

Union：

1
2
3
4
5
6
7
8
9
10

val query = database
    .from(Employees)
    .select(Employees.id)
    .unionAll(
        database.from(Departments).select(Departments.id)
    )
    .unionAll(
        database.from(Departments).select(Departments.id)
    )
    .orderBy(Employees.id.desc())

多表连接查询：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

data class Names(val name: String?, val managerName: String?, val departmentName: String?)

val emp = Employees.aliased("emp")
val mgr = Employees.aliased("mgr")
val dept = Departments.aliased("dept")

val results = database
    .from(emp)
    .leftJoin(dept, on = emp.departmentId eq dept.id)
    .leftJoin(mgr, on = emp.managerId eq mgr.id)
    .select(emp.name, mgr.name, dept.name)
    .orderBy(emp.id.asc())
    .map { row -> 
        Names(
            name = row[emp.name],
            managerName = row[mgr.name],
            departmentName = row[dept.name]
        )
    }

插入：

1
2
3
4
5
6
7
8

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

更新：

1
2
3
4
5
6
7
8

database.update(Employees) {
    set(it.job, "engineer")
    set(it.managerId, null)
    set(it.salary, 100)
    where {
        it.id eq 2
    }
}

删除：

1

database.delete(Employees) { it.id eq 4 }

这就是 Ktorm 提供的 SQL DSL，使用这套 DSL，我们可以使用纯 Kotlin 代码来编写查询，不再需要在 XML 中写 SQL，也不需要在代码中拼接 SQL 字符串。而且，强类型的 DSL 还能让我们获得一些额外的好处，比如将一些低级的错误暴露在编译期，以及 IDE 的智能提示和自动补全。最重要的是，它生成的 SQL 几乎与我们的 Kotlin 代码一一对应，因此虽然我们的 SQL 是自动生成的，我们仍然对它拥有绝对的控制。

这套 DSL 几乎可以覆盖我们工作中常见的所有 SQL 的用法，比如 union、联表、聚合等，甚至对嵌套查询也有一定的支持。当然，肯定也有一些暂时不支持的用法，比如某些数据库中的特殊语法，或者十分复杂的查询(如相关子查询)。这其实十分罕见，但如果真的发生，Ktorm 也提供了一些解决方案：

• Ktorm 可以方便的对 SQL DSL 进行扩展，以支持某些数据库中的特殊语法，这些扩展主要以独立的 jar 包提供，比如 ktorm-support-mysql。当然，我们也能自己编写扩展。
• 对于确实无法支持的情况，Ktorm 也可以直接使用原生 SQL 进行查询，并额外提供了一些方便的扩展函数支持。

更多 SQL DSL 的用法，请参考 Ktorm 的具体文档。

实体类与列绑定

前面我们已经介绍了 SQL DSL，但是如果只有 DSL，Ktorm 还远不能称为一个 ORM 框架。接下来我们将介绍实体类的概念，了解如何将数据库中的表与实体类进行绑定，这正是 ORM 框架的核心：对象 - 关系映射。

我们仍然以前面的部门表 t_department 和员工表 t_employee 为例，创建两个 Ktorm 的实体类，分别用来表示部门和员工这两个业务概念：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

interface Department : Entity<Department> {
    companion object : Entity.Factory<Department>()
    val id: Int
    var name: String
    var location: String
}

interface Employee : Entity<Employee> {
    companion object : Entity.Factory<Employee>()
    val id: Int?
    var name: String
    var job: String
    var manager: Employee?
    var hireDate: LocalDate
    var salary: Long
    var department: Department
}

可以看到，Ktorm 中的实体类都继承了 Entity<E> 接口，这个接口为实体类注入了一些通用的方法。实体类的属性则使用 var 或 val 关键字直接定义即可，根据需要确定属性的类型及是否为空。

有一点可能会违背你的直觉，Ktorm 中的实体类并不是 data class，甚至也不是一个普通的 class，而是 interface。这是 Ktorm 的设计要求，通过将实体类定义为 interface，Ktorm 才能够实现一些特别的功能，以后你会了解到它的意义。

众所周知，接口并不能实例化，既然实体类被定义为接口，我们要如何才能创建一个实体对象呢？其实很简单，只需要像下面这样，假装它有一个构造函数：

1

val department = Department()

有心的同学应该已经发现，上面定义实体类接口的时候，还为这两个接口都增加了一个伴随对象。这个伴随对象重载了 Kotlin 中的 invoke 操作符，因此可以使用括号像函数一样直接调用。在 Ktorm 的内部，我们使用了 JDK 的动态代理创建了实体对象。

还记得在上一节中我们定义的两个表对象吗？现在我们已经有了实体类，下一步就是把实体类和前面的表对象进行绑定。这个绑定其实十分简单，只需要在声明列之后继续链式调用 bindTo 函数或 references 函数即可，下面的代码修改了前面的两个表对象，完成了 ORM 绑定：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

object Departments : Table<Department>("t_department") {
    val id = int("id").primaryKey().bindTo { it.id }
    val name = varchar("name").bindTo { it.name }
    val location = varchar("location").bindTo { it.location }
}

object Employees : Table<Employee>("t_employee") {
    val id = int("id").primaryKey().bindTo { it.id }
    val name = varchar("name").bindTo { it.name }
    val job = varchar("job").bindTo { it.job }
    val managerId = int("manager_id").bindTo { it.manager.id }
    val hireDate = date("hire_date").bindTo { it.hireDate }
    val salary = long("salary").bindTo { it.salary }
    val departmentId = int("department_id").references(Departments) { it.department }
}

命名规约：强烈建议使用单数名词命名实体类，使用名词的复数形式命名表对象，如：Employee/Employees、Department/Departments。

把两个表对象与修改前进行对比，我们可以发现两处不同：

1. Table 类的泛型参数，我们需要指定为实体类的类型，以便 Ktorm 将表对象与实体类进行绑定；在之前，我们设置为 Nothing 表示不绑定到任何实体类。
2. 在每个列声明函数的调用后，都链式调用了 bindTo 或 references 函数将该列与实体类的某个属性进行绑定；如果没有这个调用，则不会绑定到任何属性。

列绑定的意义在于，通过查询从数据库中获取实体对象的时候，Ktorm 会根据我们的绑定配置，将某个列的数据填充到它所绑定的属性中去；在将实体对象中的修改更新到数据库中的时候（使用 flushChanges 函数），Ktorm 也会根据我们的绑定配置，将某个属性的变更，同步更新到绑定它的那个列。

完成列绑定后，我们就可以使用序列 API 对实体进行各种灵活的操作。我们先给 Database 定义两个扩展属性，它们使用 sequenceOf 函数创建序列对象并返回。这两个属性可以帮助我们提高代码的可读性：

1
2

val Database.departments get() = this.sequenceOf(Departments)
val Database.employees get() = this.sequenceOf(Employees)

下面的代码使用 find 函数从序列中根据名字获取一个 Employee 对象：

1

val employee = database.employees.find { it.name eq "vince" }

我们还能使用 filter 函数对序列进行筛选，比如获取所有名字为 vince 的员工：

1

val employees = database.employees.filter { it.name eq "vince" }.toList()

find 和 filter 函数都接受一个 lambda 表达式作为参数，使用该 lambda 的返回值作为条件，生成一条查询 SQL。可以看到，生成的 SQL 自动 left jion 了关联表 t_department：

1
2
3
4

select * 
from t_employee 
left join t_department _ref0 on t_employee.department_id = _ref0.id 
where t_employee.name = ?

将实体对象保存到数据库：

1
2
3
4
5
6
7
8
9

val employee = Employee {
    name = "jerry"
    job = "trainee"
    hireDate = LocalDate.now()
    salary = 50
    department = database.departments.find { it.name eq "tech" }
}

database.employees.add(employee)

将内存中实体对象的变化更新到数据库：

1
2
3
4

val employee = database.employees.find { it.id eq 2 } ?: return
employee.job = "engineer"
employee.salary = 100
employee.flushChanges()

从数据库中删除实体对象：

1
2

val employee = database.employees.find { it.id eq 2 } ?: return
employee.delete()

更多实体 API 的用法，可参考列绑定和实体查询相关的文档。

可以看到，只需要将表对象与实体类进行绑定，我们就可以使用这些方便的函数，大部分对实体对象的增删改查操作，都只需要一个函数调用即可完成，但 Ktorm 能做到的，还远不止于此。

实体序列 API

Ktorm 提供了一套名为”实体序列”的 API，用来从数据库中获取实体对象。正如其名字所示，它的风格和使用方式与 Kotlin 标准库中的序列 API 极其类似，它提供了许多同名的扩展函数，比如 filter、map、reduce 等。

Ktorm 的实体序列 API，大部分都是以扩展函数的方式提供的，这些扩展函数大致可以分为两类，它们分别是中间操作和终止操作。

中间操作

这类操作并不会执行序列中的查询，而是修改并创建一个新的序列对象，比如 filter 函数会使用指定的筛选条件创建一个新的序列对象。下面使用 filter 获取部门 1 中的所有员工：

1

val employees = database.employees.filter { it.departmentId eq 1 }.toList()

可以看到，用法几乎与 kotlin.sequences 完全一样，不同的仅仅是在 lambda 表达式中的等号 == 被这里的 eq 函数代替了而已。filter 函数还可以连续使用，此时所有的筛选条件将使用 and 运算符进行连接，比如：

1
2
3
4

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

生成 SQL：

1
2
3
4

select * 
from t_employee 
left join t_department _ref0 on t_employee.department_id = _ref0.id 
where (t_employee.department_id = ?) and (t_employee.manager_id is not null)

使用 sortedBy 或 sortedByDescending 对序列中的元素进行排序：

1

val employees = database.employees.sortedBy { it.salary }.toList()

使用 drop 和 take 函数进行分页：

1

val employees = database.employees.drop(1).take(1).toList()

终止操作

实体序列的终止操作会马上执行一个查询，获取查询的执行结果，然后执行一定的计算。for-each 循环就是一个典型的终止操作，下面我们使用 for-each 循环打印出序列中所有的员工：

1
2
3

for (employee in database.employees) {
    println(employee)
}

生成的 SQL 如下：

1
2
3

select * 
from t_employee 
left join t_department _ref0 on t_employee.department_id = _ref0.id

toCollection、toList 等方法用于将序列中的元素保存为一个集合：

1

val employees = database.employees.toCollection(ArrayList())

mapColumns 函数用于获取指定列的结果：

1

val names = database.employees.mapColumns { it.name }

除此之外，mapColumns 还可以同时获取多个列的结果，这时我们只需要在闭包中使用 tupleOf 包装我们的这些字段，函数的返回值也相应变成了 List<TupleN<C1?, C2?, .. Cn?>>：

1
2
3
4
5
6

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

生成 SQL：

1
2
3

select t_employee.id, t_employee.name
from t_employee 
where t_employee.department_id = ?

其他我们熟悉的序列函数也都支持，比如 fold、reduce、forEach 等，下面使用 fold 计算所有员工的工资总和：

1
2
3
4

val totalSalary = database.employees
    .fold(0L) { acc, employee -> 
        acc + employee.salary 
    }

序列聚合

实体序列 API 不仅可以让我们使用类似 kotlin.sequences 的方式获取数据库中的实体对象，它还支持丰富的聚合功能，让我们可以方便地对指定字段进行计数、求和、求平均值等操作。

下面使用 aggregateColumns 函数获取部门 1 中工资的最大值：

1
2
3

val max = database.employees
    .filter { it.departmentId eq 1 }
    .aggregateColumns { max(it.salary) }

如果你希望同时获取多个聚合结果，只需要在闭包中使用 tupleOf 包装我们的这些聚合表达式即可，此时函数的返回值就相应变成了 TupleN<C1?, C2?, .. Cn?>。下面的例子获取部门 1 中工资的平均值和极差：

1
2
3

val (avg, diff) = database.employees
    .filter { it.departmentId eq 1 }
    .aggregateColumns { tupleOf(avg(it.salary), max(it.salary) - min(it.salary)) }

生成 SQL：

1
2
3

select avg(t_employee.salary), max(t_employee.salary) - min(t_employee.salary) 
from t_employee 
where t_employee.department_id = ?

除了直接使用 aggregateColumns 函数以外，Ktorm 还为序列提供了许多方便的辅助函数，他们都是基于 aggregateColumns 函数实现的，分别是 count、any、none、all、sumBy、maxBy、minBy、averageBy。

下面改用 maxBy 函数获取部门 1 中工资的最大值：

1
2
3

val max = database.employees
    .filter { it.departmentId eq 1 }
    .maxBy { it.salary }

除此之外，Ktorm 还支持分组聚合，只需要先调用 groupingBy，再调用 aggregateColumns。下面的代码可以获取所有部门的平均工资，它的返回值类型是 Map<Int?, Double?>，其中键为部门 ID，值是各个部门工资的平均值：

1
2
3

val averageSalaries = database.employees
    .groupingBy { it.departmentId }
    .aggregateColumns { avg(it.salary) }

生成 SQL：

1
2
3

select t_employee.department_id, avg(t_employee.salary) 
from t_employee 
group by t_employee.department_id

在分组聚合时，Ktorm 也提供了许多方便的辅助函数，它们是 eachCount(To)、eachSumBy(To)、eachMaxBy(To)、eachMinBy(To)、eachAverageBy(To)。有了这些辅助函数，上面获取所有部门平均工资的代码就可以改写成：

1
2
3

val averageSalaries = database.employees
    .groupingBy { it.departmentId }
    .eachAverageBy { it.salary }

除此之外，Ktorm 还提供了 aggregate、fold、reduce 等函数，它们与 kotlin.collections.Grouping 的相应函数同名，功能也完全一样。下面的代码使用 fold 函数计算每个部门工资的总和：

1
2
3
4
5

val totalSalaries = database.employees
    .groupingBy { it.departmentId }
    .fold(0L) { acc, employee -> 
        acc + employee.salary 
    }

更多实体序列 API 的用法，可参考实体序列和序列聚合相关的文档。

小结

本文从一个 “Hello, World” 程序开始，对 Ktorm 的几大特性进行了介绍，它们分别是 SQL DSL、实体类与列绑定、实体序列 API 等。有了 Ktorm，我们就可以使用纯 Kotlin 代码方便地完成数据持久层的操作，不需要再使用 MyBatis 烦人的 XML。同时，由于 Ktorm 是专注于 Kotlin 语言的框架，因此没有兼容 Java 的包袱，能够让我们更加充分地使用 Kotlin 各种优越的语法特性，写出更加优雅的代码。既然语言都已经切换到 Kotlin，为何不尝试一下纯 Kotlin 的框架呢？

Enjoy Ktorm, enjoy Kotlin!

本文来自我的知乎回答：找到编译器的bug是种怎样的体验？ - 知乎

emmm…这个问题下面真的是大佬云集，萌新感到好忐忑…

前段时间在使用 Kotlin 开发一个 ORM 框架（广告慎入，Ktorm：专注于 Kotlin 的 ORM 框架），当时我的代码大概是这样的，定义了一个 Foo 接口，在这个接口里面写了个默认实现的 bar() 方法：

1
2
3
4
5
6
7
8
9
10
11

interface Foo {
    fun bar() {
        val obj = object : Any() { }
        println(obj.javaClass.simpleName)
    }
}

fun main(args: Array<String>) {
    val foo = object : Foo { }
    foo.bar()
}

怎么样，看起来是不是稳如狗？然而，这段代码在运行的时候，却喷了我一脸异常：

1
2
3
4
5
6
7
8

Exception in thread "main" java.lang.InternalError: Malformed class name
    at java.lang.Class.getSimpleBinaryName(Class.java:1450)
    at java.lang.Class.getSimpleName(Class.java:1309)
    ...
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -3
    at java.lang.String.substring(String.java:1931)
    at java.lang.Class.getSimpleBinaryName(Class.java:1448)
    ... 4 more

风中凌乱…我不就是想输出一下匿名对象的类名吗，这个 InternalError 是什么鬼…

惊讶之余，冷静下来好好理了理 Kotlin 生成 class 的规则，终于明白过来。

众所周知，在 Java 中，interface 里面是不能有方法实现的（Java 8 以前），然而，Kotlin 却可以直接在接口里面实现方法。我们知道，Kotlin 最终也是要编译成 Java 字节码，既然 Java 本身都不支持这种操作，Kotlin 是怎么做到的呢？

反编译 Kotlin 生成的字节码就可以看到，在编译出来的 interface Foo 中，bar 方法仍然是 abstract 的，并没有实现。但是，Kotlin 另外生成了一个 Foo$DefaultImpls 类，在这个类里面有一个静态方法，这个方法的签名是：

1

public static void bar(Foo $this)

这个方法里面的字节码，就是我们的 bar() 方法的默认实现了。这样，当一个 Kotlin 的类实现了 Foo 接口时，编译器就会自动为我们插入一个 bar() 方法的实现，这个实现只是简单调用了 Foo$DefaultImpls 里面的静态方法：

1
2
3
4

@Override
public void bar() {
    DefaultImpls.bar(this);
}

这就是 Kotlin 中接口默认方法的实现原理。

然而这跟前面的 bug 又有什么关系…

我们回过头来看刚刚出 bug 的代码，可以看到一个 object : Any() { }，这应该会生成一个匿名内部类，看下编译结果，可以知道这个匿名内部类的名字是 Foo$bar$obj$1，这应该没什么特别的。

然后顺着异常栈去到 JDK 的 Class 类里面，看源码，可以看到报错的地方是这样的：

1
2
3
4
5
6
7
8
9
10
11

private String getSimpleBinaryName() {
    Class<?> enclosingClass = getEnclosingClass();
    if (enclosingClass == null) // top level class
        return null;
    // Otherwise, strip the enclosing class' name
    try {
        return getName().substring(enclosingClass.getName().length());
    } catch (IndexOutOfBoundsException ex) {
        throw new InternalError("Malformed class name", ex);
    }
}

额，好像找到原因了…

回到前面提到的匿名内部类 Foo$bar$obj$1，因为 bar() 方法是在 Foo$DefaultImpls 中实现的，所以对这个匿名类获取 enclosingClass 毫无疑问就是 Foo$DefaultImpls 了，然后在 substring 的时候就 GG 了…

最后，根据我粗浅的理解，应该可以得出结论，这个 bug 的根源是 Kotlin 在编译这个匿名内部类的时候生成的名字有误，如果生成的名字是 Foo$DefaultImpls$bar$obj$1 的话，bug 就不会发生。带着这个疑惑，我去 Kotlin issue 上面找了找，果然已经有人提出过这个问题，然而这个 issue 至今都是 open 状态，并没有得到解决，难道是这个 bug 会牵扯到其他地方？有兴趣的同学可以去看一看：Names for anonymous classes in interfaces are malformed : KT-16727

最终，bug 的原因是找到了，那在 Kotlin 修复这个 bug 之前应该怎么办呢？我们当然只能想办法绕过了，比如避免在接口的默认实现方法中使用匿名内部类，lambda 也不行，因为 Kotlin 的 lambda 也会编译成匿名类…

BTW，说到编译器的 bug，之前在使用 Java 8 的 lambda 的时候也遇到过一个，当时还在知乎吐槽了一下，这里也贴个链接，仅作记录：此处的lambda为什么不能用方法引用表示 - 知乎

以上

Java 异常简介

众所周知，Java 的所有异常都派生自 Throwable 类，在继承结构上，从 Throwable 派生出了 Error 和 Exception 两大类。其中，Error 表示系统级别的严重程序错误，一般由 JVM 抛出，我们也不应该捕获这类异常，用户自定义的异常一般都派生自 Exception 类。

从是否被编译器强制检查一点，异常又可分为受检异常(Checked Exception)和未受检异常(Unchecked Exception)。未受检异常派生自 Error 或者 RuntimeException，表示不可恢复的程序错误，典型例子有 AssertionError、NullPointerException 等，编译器不会强制我们捕获这类异常。受检异常则是除了 Error/RuntimeException 之外，派生自 Throwable 或者 Exception 的其他异常，比如 IOException、SQLException 等。如果一个方法声明自己可能抛出受检异常，那么编译器会强制它的调用者必须使用 try-catch 捕获此异常，或者在自己的方法中加上 throws 声明将异常继续传播给外界。

多年以来，Java 中受检异常的设计一直颇受争议，反对者认为，受检异常容易破坏方法声明的兼容性，会使代码的可读性降低，还增加开发的工作量等等。当然也有一些支持者，他们认为受检异常可以强迫程序员去思考，有助于他们写出更健壮的代码，可以参考王垠的文章「Kotlin 和 Checked Exception」。

在这里，我不想继续讨论受检异常到底是好还是坏，我只想以这个为切入点，随便讨论一点关于 Java 的八卦。

Checked/unchecked, who cares?

上面讲过，如果一个方法可能抛出受检异常，就必须在方法上加上 throws 声明，也就是说，如果方法上没有 throws 声明，这个方法就不可能抛出受检异常吗？按照 Java 的语言规范，这当然不可能，否则受检异常不就名不符实了吗？

当然说话也不能这么绝对，作为一个程序员，我们在自认为不可能的地方找到的 bug 还少吗？Test first，我们先来看一段测试代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

interface SneakyThrows {

    /**
     * Throws an IOException sneakily.
     */
    void sneakyThrow() /* throws IOException */;
}

static void testSneakyThrows(SneakyThrows sneaky) {
    try {
        sneaky.sneakyThrow();
    } catch (Throwable e) {
        if (e instanceof IOException) {
            System.out.println(sneaky.getClass().getSimpleName() + " success!");
        } else {
            throw new AssertionError(
                sneaky.getClass().getSimpleName() + " failed!", e);
        }
    }
}

这是一个接口和一个测试方法。这个 SneakyThrows 接口自称它会抛出一个 IOException，然而它的方法上却没有 throws 声明。测试方法接受一个实现了 SneakyThrows 接口的对象，调用接口上的 sneakyThrow 方法，如果接口方法真的抛出了 IOException，则输出 success 字样，否则会抛出异常，测试失败。那么，聪明的你，有没有办法实现这样一个接口，使测试能够成功呢？

当然有，而且还不止一种方法！

万能的 Unsafe

在 Java 里，说到黑科技，大家总是会首先想到 sun.misc.Unsafe，这个类大量出现在 JDK 源码以及各种第三方类库的源码中，用于实现一些奇奇怪怪的功能。那么它能不能用来抛出一个受检异常呢？当然能，Unsafe 中刚好有一个 throwException 方法可以实现这个功能。可惜的是，获取 Unsafe 对象只有一个 Unsafe.getUnsafe() 方法，而这个方法中加了对调用者的检查，只有 jdk 中的类才能调用这个方法，否则将抛出 SecurityException。

但是我们还有反射，只要 Unsafe 对象是保存在一个 Java 的字段中，反射就可以直接拿到这个对象，无视访问权限以及安全检查。下面这段代码，首先通过反射得到了 Unsafe 对象，然后调用它的 throwException 方法，成功抛出了一个受检异常。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class UnsafeSneakyThrows implements SneakyThrows {

    @Override
    public void sneakyThrow() {
        getUnsafe().throwException(new IOException());
    }

    Unsafe getUnsafe() {
        try {
            Field field = Unsafe.class.getDeclaredField("theUnsafe");
            field.setAccessible(true);
            return (Unsafe) field.get(null);
        } catch (NoSuchFieldException | IllegalAccessException e) {
            throw new IllegalStateException(e);
        }
    }
}

小伙伴们可以运行一下，这段代码完全做到我们之前认为不可能的事情，在一个没有 throws 声明的方法里抛出受检异常！这时，有心的小伙伴应该就能明白过来，所谓的受检不受检，其实只是一个编译器的魔法，JVM 是完全不关心的。这也是为什么基于 JVM 的其他语言，比如 Scala、Groovy 之类，完全抛弃了受检异常的设计，却能运行在 JVM 上，并且能和 Java 很好地兼容。另外，学过 C++ 的同学应该也知道，在 C++ 里面，异常并不像 Java 一样有一个共同的基类，C++ 的 throw 语句可以抛出任何东西，甚至直接抛出一个 int 之类的值类型，当然这是题外话。

通过 Unsafe，我们能玩的黑魔法还有很多，比如分配一段非托管的直接内存、绕过 Java 的类初始化机制直接创建一个未初始化的对象、通过偏移量直接修改任何对象内的字段、以及硬件级别的原子操作 CAS 等。正因如此，它的身影也在 JDK 源码和各种第三方类库中频繁出现。比如 concurrent 包中使用它实现了各种线程同步相关的工具类以及 AtomicXxx 系的各种无锁的原子操作；nio 使用它获得了直接操作裸内存的能力；netty 也因为它得以直接操作堆外内存，大大地提升了性能；各类序列化库也使用它绕过类初始化机制、以方便地实现反序列化。

然而，这种大杀器一般都会有很大的副作用，比如分配的非托管内存，如果不注意释放，很容易就造成内存泄露，其他的操作也往往是高危操作，正如其 Unsafe 的名字。有消息称，在 JDK9 中，随着新的模块系统的推出，真正杜绝了应用直接使用 Unsafe 类，到时这个黑魔法就不管用咯，可以看看 R 大在知乎的回答：「为什么JUC中大量使用了sun.misc.Unsafe 这个类，但官方却不建议开发者使用？ - RednaxelaFX的回答 - 知乎」。

坑爹的泛型

泛型也是那些黑 Java 的人的主要喷点之一。在 Java 中，泛型也只是编译器的语法糖，JVM 中并不保留泛型的类型信息，其名曰「类型擦除」。JDK5 推出时，Java 已在各行各业广泛使用，采用类型擦除的泛型设计也是出于兼容性考虑，否则就要像 C# 一样，同时存在 System.Collections 和 System.Collections.Generic 两套集合框架。关于泛型的更多细节，也可以看看 R 大的文章「Reifiable generics与Type erasure generics各有怎样的优点与缺点？ - RednaxelaFX的回答 - 知乎」。

然而，采用类型擦除除了大家都说烂了的那些坏处之外，还有一些不为人知的坑，比如下面这段代码就是。

1
2
3
4
5
6
7
8
9
10
11

class GenericSneakyThrows implements SneakyThrows {

    @Override
    public void sneakyThrow() {
        this.<RuntimeException>sneakyThrow0(new IOException());
    }

    <X extends Throwable> void sneakyThrow0(Throwable e) throws X {
        throw (X) e;
    }
}

这里定义了一个泛型声明为 <X extends Throwable> 方法，在内部将传入的 Throwable 强转为 X 之后再抛出，X 的具体类型取决于调用这个方法时指定的类型参数。在这里，只要将类型参数指定为 RuntimeException，然后不管传入一个什么异常，都可以直接抛出去，而不用 throws 声明。什么，你说为什么 IOException 可以强转成 RuntimeException？当然是因为类型擦除啊，由于类型擦除的存在，sneakyThrow0 在被调用的时候，X 在运行时实际上是擦除为 Throwable 类型，从 IOException 转成 Throwable 一点问题都不会有。

所以说，基于类型擦除的泛型，和受检异常的设计实际上是冲突的，如果说上面提到的 Unsafe 是内部 API，可以不允许外界调用，那么，在类型擦除和受检异常共存的 Java 里，永远也不可能解决这个问题。

顺便一提，在 JDK8 中，由于 lambda 的引入，改变了类型推断算法，上面代码中的类型参数其实是可以省略的，直接 this.sneakyThrow0(new IOException()) 即可。

Evil Class.newInstance()

在很多文章里面，都推荐大家在使用反射的时候，用 Constructor.newInstance() 代替 Class.newInstance() 创建对象，这是为什么呢？我们先看看下面这段代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class ConstructorSneakyThrows implements SneakyThrows {

    @Override
    public void sneakyThrow() {
        try {
            ConstructorThrowable.class.newInstance();
        } catch (InstantiationException | IllegalAccessException e) {
            throw new IllegalStateException(e);
        }
    }
}

class ConstructorThrowable {

    ConstructorThrowable() throws IOException {
        throw new IOException();
    }
}

和上面两个例子一样，上面这段代码也可以抛出一个受检异常。我们首先写了一个 ConstructorThrowable 类，这个类有一个无参构造方法，在构造方法里面我们抛出了一个 IOException，因此在调用 Class.newInstance() 的时候就把这个异常传播了出去，从而绕过了编译器的检查。

那么，为什么 Constructor.newInstance() 就不会有这个问题呢？对比这两者的签名就可以发现，它的 throws 列表中多了一个 InvocationTargetException，在构造方法的执行过程中如果发生了异常，这个异常会被包装为 InvocationTargetException 再次抛出。

这两个方法明明有相同的作用，但是在异常方面却有微妙的差别。查看 JDK 源码我们可以看到，Class.newInstance() 底层其实就是先获取到 Constructor 对象，然后再把实际的操作代理给 Constructor.newInstance()。然而，在这个过程中，它捕获了 InvocationTargetException，然后使用 Unsafe 将其包装的 targetException 直接抛出。

为什么 Class.newInstance() 要多次一举呢？这其实是历史原因导致的。Java 的反射 API 是在 1.2 版本引入的，而 Class 类在之前就有了，如果在 Class.newInstance() 方法的 throws 声明中也加上 InvocationTargetException 的话，由于这个异常是受检异常，就会导致基于旧版 JDK 写的代码都不能通过编译。所以为了兼容性考虑，只能使用 Unsafe 来传播构造方法中产生的异常。这也是一个证明受检异常是设计失误的例子，即容易破坏兼容性、妨碍 API 的演化。

具体的细节，在 Class.newInstance() 的 Javadoc 中已经有介绍，Stack Overflow 上也有相关的讨论，「java - Why is Class.newInstance() “evil”? - Stack Overflow」。

废弃的 Thread.stop()

在 JDK5 里面，Thread 类一口气废弃了好几个方法，它们就是 suspend/resume/stop 系列。当然，废弃归废弃，只要我们有充分的理由，也不是不能用它们。

1
2
3
4
5
6
7

class ThreadStopSneakyThrows implements SneakyThrows {

    @Override
    public void sneakyThrow() {
        Thread.currentThread().stop(new IOException());
    }
}

如你所见，接收一个 Throwable 参数的 Thread.stop() 方法也可以用来实现 SneakyThrows，抛出一个受检异常。stop() 方法的作用是使指定线程产生一个异常，从而强行终止该线程的执行。在这里，我们使当前线程产生一个 IOException，以达到我们的目的。那么它为什么被废弃了呢？JDK 文档里面有详细的解释。

This method is inherently unsafe. Stopping a thread with Thread.stop causes it to unlock all of the monitors that it has locked (as a natural consequence of the unchecked ThreadDeath exception propagating up the stack). If any of the objects previously protected by these monitors were in an inconsistent state, the damaged objects become visible to other threads, potentially resulting in arbitrary behavior. Many uses of stop should be replaced by code that simply modifies some variable to indicate that the target thread should stop running. The target thread should check this variable regularly, and return from its run method in an orderly fashion if the variable indicates that it is to stop running. If the target thread waits for long periods (on a condition variable, for example), the interrupt method should be used to interrupt the wait.

简单来说，如果一个线程已经获得了某个锁，正在执行某些互斥操作，stop() 方法会强行使这个线程失去锁，而此时，它的操作可能还没有执行完成，这就可能使变量处于不一致的状态，造成线程安全问题。

嘛，反正这个方法已经废弃了，再多说也没什么意义。值得一提的是，在 JDK8 里，带 Throwable 参数的 Thread.stop() 方法已经改成直接抛出 UnsupportedOperationException，完全不能使用了，只有无参数的重载版本还仍可使用（无参版本默认抛出 ThreadDeath）。所以上面那段代码，只有在 JDK7 及以下才有效，在 JDK8 中并不能通过测试。

The End

好了，扯淡结束。本文简单介绍了 Java 中的受检异常和未受检异常的区别，指出受检异常只是编译器的魔法、JVM 底层并不关心，并给出了四种绕过编译器检查，在任何地方都可抛出受检异常的方法。在介绍这四种方法的时候，随便讲了一些与之相关的八卦。

我的观点是，学习一门编程语言，了解一下这门语言的八卦还是很有必要的。当你知道它都有那些缺点，你就会思考，为什么当初要这样设计，你就会明白，所有的缺点，其实都是工程上的妥协。

程序员啊，还是要保持这一颗八卦的心。

荆轲刺秦王。

我们以「德州扑克」游戏的业务场景为例进行说明。「德州扑克」是一款风靡世界的扑克游戏，要实现这个游戏，首先要对系统进行建模，我们可能会写出这样的一段代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public enum PokerSuit {
    SPADE, HEART, DIAMOND, CLUB
}

public class PokerCard {
    private final int number;
    private final PokerSuit suit;

    public PokerCard(int number, PokerSuit suit) {
        if (number < 1 || number > 13) {
            throw new IllegalArgumentException("number");
        }
        this.number = number;
        this.suit = Objects.requireNonNull(suit);
    }

    public int getNumber() {
        return number;
    }

    public PokerSuit getSuit() {
        return suit;
    }
}

PokerCard 是一个十分简单的模型类，但它足以描述游戏中的一张扑克牌。其中，number 表示扑克牌的点数，1 代表 A，11 ~ 13 代表 J ~ K；suit 表示扑克牌的花色，它是一个枚举类型；因为「德州扑克」中没有大王和小王，所以在这里不作考虑。

按照约定，如果我们需要把这个类用在基于哈希集合中，就必须重写它的 hashCode 和 equals 方法。这个容易，重写就是了：

1
2
3
4
5
6
7
8
9
10
11

@Override
public int hashCode() {
    return Objects.hash(number, suit);
}

@Override
public boolean equals(Object o) {
    if (!(o instanceof PokerCard)) return false;
    PokerCard other = (PokerCard) o;
    return this.number == other.number && this.suit == other.suit;
}

另外，扑克牌之间需要比较大小，所以我们需要实现 Comparable 接口以支持比较操作。「德州扑克」比较牌的大小是单纯比较点数，忽略花色的，所以代码可能是这样：

1
2
3
4
5
6
7
8
9
10
11

public class PokerCard implements Comparable<PokerCard> {
    // ...

    @Override
    public int compareTo(PokerCard other) {
        // because 1(A) is bigger than any other number
        int thisNum = this.number == 1 ? 14 : this.number;
        int otherNum = other.number == 1 ? 14 : other.number;
        return thisNum - otherNum;
    }
}

到此为止，一切都是那么和谐，在设计上，这个类似乎没有任何问题，事实上，在大部分情况下，它也是完全可以正常工作的。

那么，现在我们需要表示一个「牌型」的概念，所谓「牌型」，在德州扑克里面，即是在玩家的手牌与桌面的公共牌中选取五张牌所组成的一个集合，在比牌时，「牌型」最大的玩家即可赢得奖池。在这个定义中，我们可以知道，「牌型」是一个集合，而且需要支持比较操作，因此我们可以让它实现 Set 和 Comparable 接口。在实际操作中，我们一般不会直接实现 Set 接口，而是选择继承 AbstractSet 类以减少代码量，因此，代码可能是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

public class PokerCombination 
        extends AbstractSet<PokerCard> implements Comparable<PokerCombination> {
    private final SortedSet<PokerCard> cards;

    public PokerCombination(Collection<PokerCard> cards) {
        if (cards == null || cards.size() != 5) { 
            throw new IllegalArgumentException("cards");
        }
        this.cards = Collections.unmodifiableSortedSet(new TreeSet<>(cards));
    }

    @Override
    public Iterator<PokerCard> iterator() {
        return cards.iterator();
    }

    @Override
    public int size() {
        return cards.size();
    }

    @Override
    public int compareTo(PokerCombination o) {
        // compare the poker combinations
        return 0;
    }
}

在这里，我们省略了 compareTo 方法的具体代码，但是，为了方便实现比较操作， 在PokerCombination 类的内部实现中，采用了 SortedSet，这是一个有序的集合，在其中的元素都会按照其自然顺序（即 Comparable.compareTo 方法定义的顺序）进行排序，TreeSet 是它的一个常见的实现类。

现在我们添加一个测试方法，测试这个类的行为是否正确：

1
2
3
4
5
6
7
8
9
10
11
12
13

@Test
public void testSize() {
    Set<PokerCard> cards = new HashSet<>();
    cards.add(new PokerCard(1, PokerSuit.CLUB));
    cards.add(new PokerCard(1, PokerSuit.HEART));
    cards.add(new PokerCard(2, PokerSuit.CLUB));
    cards.add(new PokerCard(3, PokerSuit.CLUB));
    cards.add(new PokerCard(4, PokerSuit.CLUB));
    assertEquals(5, cards.size());

    PokerCombination combination = new PokerCombination(cards);
    assertEquals(5, combination.size());
}

这个测试方法非常简单，它首先创建了一个集合，往里面添加了 5 张扑克牌，断言它的长度是 5，然后用这个集合构造了一个 PokerCombination 对象，再断言它的长度也是 5。就这样一个简单的测试，它几乎一定会运行成功，在很多人眼里，甚至都没有写这个它的必要。

然而，当你真的运行这个测试的时候，它却失败了，错误信息如下：

1
2
3

java.lang.AssertionError: 
Expected :5
Actual   :4

这是一个断言错误，发生在我们的第二次 assertEquals 调用时，我们期望 PokerCombination 的长度是 5，然而它却是 4。现在问题来了，为什么一个长度为 5 的集合，传入 PokerCombination 里面，却变成了 4 呢？这里面发生的事情，仅仅是将传入的集合复制到一个 SortedSet 里面而已。

我们尝试将 SortedSet 换成更为通用的 Set，将 TreeSet 换成 HashSet，发现测试能正常执行，但是换回 SortedSet 的时候，它又失败了，因此，问题一定与 SortedSet 有关。打开它的源码，查看 JavaDoc，我们看到了下面这段描述：

Note that the ordering maintained by a sorted set (whether or not an explicit comparator is provided) must be consistent with equals if the sorted set is to correctly implement the Set interface. (See the Comparable interface or Comparator interface for a precise definition of consistent with equals.) This is so because the Set interface is defined in terms of the equals operation, but a sorted set performs all element comparisons using its compareTo (or compare) method, so two elements that are deemed equal by this method are, from the standpoint of the sorted set, equal. The behavior of a sorted set is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the Set interface.

大概解释一下：如果要使 SortedSet 正确表现出与普通的 Set 相同的行为，那么它内部元素的顺序关系必须要「与 equals 一致（consistent with equals）」。这是因为 Set 使用 equals 方法判断元素的等同性，而 SortedSet 使用的是 compareTo 方法，即如果 compareTo 方法返回 0，SortedSet 就认为这两个元素是相等的。当 compareTo 与 equals 的一致性不能满足时，SortedSet 的行为就会违背 Set 接口的通用约定。

那么，什么叫「与 equals 一致（consistent with equals）」呢，Comparable 接口的 JavaDoc 里面有明确的定义。对于任意非空变量 x 和 y，满足 (x.compareTo(y)==0) == (x.equals(y))，即认为 compareTo 与 equals 一致。任何实现了 Comparable，但是并没有满足这个条件的类，都应该在自己的文档中明确注明这一点。

It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y)). Generally speaking, any class that implements the Comparable interface and violates this condition should clearly indicate this fact. The recommended language is “Note: this class has a natural ordering that is inconsistent with equals.”

然而，Comparable 接口对这种一致性的约定也只是「建议」，而不是必须严格执行的规则。当然，这是可以理解的，毕竟在现实世界中，这种不一致也是存在的。就比如我们现在这个业务场景，当我们比较两张扑克牌是否相同，需要同时考虑花色和点数，当我们只是比较它们的大小时，就会忽略它们的花色。因此当 x.compareTo(y) == 0 时，x.equals(y) 是不确定的。这就是 compareTo 与 equals 不一致的情况，这种不一致是合理的。

JDK 标准库中也有这种不一致的情况，比如 BigDecimal 类。如果你创建一个 HashSet 实例，并且添加 new BigDecimal("1.0") 和 new BigDecimal("1.00")，这个集合就将包含两个元素，因为新增到集合中的两个 BigDecimal 实例，通过 equals 方法来比较时是不相等的。然而，如果你把 HashSet 换成 TreeSet，集合中将只包含一个元素，因为这两个实例在使用 compareTo 方法来比较时是相等的。

在大部分情况下，如果我们的类并没有遵守这种一致性，一般也没有什么问题。但是如果要把这个类用在有序集合中的时候，可能就需要做一点设计上的权衡。在「德州扑克」这个场景中，我们可以在 new TreeSet<>() 的时候，额外提供一个与 equals 一致的 Comparator，使这个集合能够正确地遵守通用的约定。如果项目中使用到 SortedSet 的地方不止这一处，我们也可以妥协，提供一个与 equals 一致的 compareTo 方法，但是在真正需要比较牌的大小的时候，使用另外的 compareIgnoreSuit 方法，比如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public class PokerCard implements Comparable<PokerCard> {
    // ...

    @Override
    public int compareTo(PokerCard other) {
        int diff = compareIgnoreSuit(other);
        if (diff != 0) {
            return diff;
        } else {
            return this.suit.compareTo(other.suit);
        }
    }

    public int compareIgnoreSuit(PokerCard other) {
        // because 1(A) is bigger than any other number
        int thisNum = this.number == 1 ? 14 : this.number;
        int otherNum = other.number == 1 ? 14 : other.number;
        return thisNum - otherNum;
    }
}

这样改过代码之后，之前的那个测试当然能通过，讨论也已基本结束，但是，我们的思考却不应该止步于此。正如题目所言，我把这个称为一个「坑」，但是在 SortedSet 的文档描述中，它却是一个 well-defined feature. 虽然文档中已经有了「免责声明」，但还是有不止一人曾经跳入这个「坑」里面，究其原因，恐怕与 SortedSet 继承了 Set 脱离不了干系。

继承了一个接口，却不遵守这个接口的约定，这实在让人难以理解。既然 SortedSet 无法使用 equals 来判断元素的等同性，就应该另立门户，成为一个独立的接口，而不是选择继承 Set。根据里氏替换原则(Liskov Substitution Principle LSP)，当我们把程序中的 Set 替换成其子接口 SortedSet 时，程序还应该能正常工作，SortedSet 并不能做到这一点，这正是其继承了 Set，却没有遵守 Set 的契约导致的。当然，标准库的设计者作出这个决策，应该也是权衡了利弊的结果，毕竟，直接继承 Set 可以方便地进行向上转型，方便使用者对 SortedSet 和其他的 Set 进行统一的处理。然而，如果我们把 SortedSet 独立为一个接口，也可以提供一个 asSet 视图方法，方便使用者在需要的时候将它视为一个 Set。因此我认为，选择让 SortedSet 继承 Set，是个弊大于利的决策。

以上只是对类库设计的一点拙见，班门弄斧，如果您有不同意见，欢迎讨论。

在开始之前，我们先来念两句诗，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12

public static void main(String[] args) {
    recitePoems(false);
    recitePoems(true);
}

private static void recitePoems(Boolean b) {
    if (b) {
        System.out.println("苟利国家生死以");
    } else {
        System.out.println("岂因祸福避趋之");
    }
}

上面代码的输出是：

1
2

岂因祸福避趋之
苟利国家生死以

不对呀，反了反了，念诗都念错，姿势水平还是太低。怎么改呢，很简单，把两次 recitePoems 方法调用的参数调转过来就可以了？ naïve，本文的目的是介绍黑科技，当然不会用这种寻常的办法解决问题。

不卖关子了，直接上代码吧：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

private static void doSomeMagic() throws Exception {
    Field modifiersField = Field.class.getDeclaredField("modifiers");
    modifiersField.setAccessible(true);

    Field trueField = Boolean.class.getDeclaredField("TRUE");
    modifiersField.set(trueField, trueField.getModifiers() & ~Modifier.FINAL);

    Field falseField = Boolean.class.getDeclaredField("FALSE");
    modifiersField.set(falseField, falseField.getModifiers() & ~Modifier.FINAL);

    Boolean trueValue = true;
    trueField.set(null, false);
    falseField.set(null, trueValue);
}

接下来，只需要在 main 方法的开头调用这个名为 doSomeMagic 的膜法方法就好了：

1
2
3
4
5
6

public static void main(String[] args) throws Exception {
    doSomeMagic();

    recitePoems(false);
    recitePoems(true);
}

修改完毕之后，我们得到了期望的输出：

1
2

苟利国家生死以
岂因祸福避趋之

那么，doSomeMagic 方法到底干了什么呢？很简单，它交换了 Boolean.TRUE 和 Boolean.FALSE 的值。为了能够重写它们的值，我们需要去掉它们的 final 修饰符，这就是 xxxField.getModifiers() & ~Modifier.FINAL 的作用。

交换 Boolean.TRUE 和 Boolean.FALSE 的值，为什么能够改变原代码的运行逻辑呢？我们看到，recitePoems 方法的形参是 boolean 的包装类型 Boolean，直接将 true 和 false 作为实参调用它时，将会发生自动装箱操作。而自动装箱操作是通过调用 Boolean.valueOf() 方法完成的，我们看看这个方法的源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/**
 * Returns a {@code Boolean} instance representing the specified
 * {@code boolean} value.  If the specified {@code boolean} value
 * is {@code true}, this method returns {@code Boolean.TRUE};
 * if it is {@code false}, this method returns {@code Boolean.FALSE}.
 * If a new {@code Boolean} instance is not required, this method
 * should generally be used in preference to the constructor
 * {@link #Boolean(boolean)}, as this method is likely to yield
 * significantly better space and time performance.
 *
 * @param  b a boolean value.
 * @return a {@code Boolean} instance representing {@code b}.
 * @since  1.4
 */
public static Boolean valueOf(boolean b) {
    return (b ? TRUE : FALSE);
}

可以看到，Boolean.valueOf() 方法直接使用了 Boolean.TRUE 和 Boolean.FALSE 两个常量。这就是我们能做到如此“是非颠倒”的原因。

所以说，一个程序的命运啊，当然要靠自我的奋斗，但也要考虑历史的进程。你绝对不会知道，好好的一个 true，怎么就变成 false 了呢。

这篇文章讲了这么久也没别的，大概三件事：一个，去掉 Boolean.TRUE 和 Boolean.FALSE 的 final 修饰符；第二个，交换了它们的值；第三个，就是基本类型自动装箱的细节；如果说还有一点成绩，那就是在公司每个项目的 main 方法上调用了一下 doSomeMagic 方法，这对于被炒鱿鱼的命运有很大的关系。

很惭愧，就做了一点微小的工作，谢谢大家。

英文原文是Matt Warren发表在MSDN Blogs的系列文章之一，英文渣渣，翻译不供参考，请直接看原文。

现在写一篇新的文章的时间变得越来越长，似乎已经成了一个趋势了。要怪就怪电视编剧罢工吧，嗯。

Cleaning up the Mess

我之前说过要把我们的查询翻译器不断累积下来的不必要的嵌套select表达式给清理掉。对于人类的大脑来说，简化一条SQL是一件很简单的事情。但是，对于计算机程序而言，保留这些无用的嵌套查询却更加容易，毕竟它们的语义是一样的。再者，我们希望少写一点代码的心情也无可厚非。

我们很容易就能从一条带有where子句的简单的查询中看出问题所在。

1
2
3

from c in db.Customers
where c.Country == "UK"
select c;

这条普通的查询将翻译为下面的SQL：

1
2
3
4
5
6

SELECT t1.Country, t1.CustomerID, t1.ContactName, t1.Phone, t1.City
FROM (
  SELECT t0.Country, t0.CustomerID, t0.ContactName, t0.Phone, t0.City
  FROM Customers AS t0
) AS t1
WHERE (t1.Country = 'UK')

为什么会有一个多余的SELECT？如果你理解了我们的翻译器的工作方式，并且知道这条LINQ查询的本质是什么的话，很容易就能知道答案。

这条LINQ查询的方法调用语法如下：

1

db.Customers.Where(c => c.Country == "UK").Select(c => c);

这里面有两个LINQ查询操作符，Where()和Select()。我们在QueryBinder类中的翻译引擎将这两个方法调用翻译为两个独立的SelectExpression。

理想情况下，SQL查询应该如下所示：

1
2
3

SELECT t0.Country, t0.CustomerID, t0.ContactName, t0.Phone, t0.City
FROM Customers AS t0
WHERE (t0.Country = 'UK')

然而，这只是很简单的情况，随着操作符的增加，所生成的SQL会越来越槽糕。你觉得翻译器能够聪明到将多个where子句合并到一起吗？我确实没有添加任何代码。如果语言编译器能够帮我们完成这个工作就再好不过了，但是如果额外的where子句是在原查询已经创建完成之后添加到其中的又会如何呢？

1
2
3
4
5
6
7
8

var query = 
    from c in db.Customers
    where c.Country == "UK"
    select c;
// ...
query = from c in query
        where c.Phone == "555-5555"
        select c;

这样翻译出来的SQL就变成了一个三层的庞然大物，可它又不能吃，要那么大干嘛。

1
2
3
4
5
6
7
8
9
10

SELECT t2.CustomerID, t2.ContactName, t2.Phone, t2.City, t2.Country
FROM (
  SELECT t1.CustomerID, t1.ContactName, t1.Phone, t1.City, t1.Country
  FROM (
    SELECT t0.CustomerID, t0.ContactName, t0.Phone, t0.City, t0.Country
    FROM Customers AS t0
  ) AS t1
  WHERE (t1.Country = 'UK')
) AS t2
WHERE (t2.Phone = '555-5555')

不仅如此，我只是添加了一个小小的投影，翻译器都会额外创建一个嵌套查询。

1
2
3
4

var query = 
    from c in db.Customers
    where c.Country == "UK"
    select c.CustomerID;

翻译出来的SQL如下：

1
2
3
4
5
6
7
8
9

SELECT t2.CustomerID
FROM (
  SELECT t1.CustomerID, t1.ContactName, t1.Phone, t1.City, t1.Country
  FROM (
    SELECT t0.CustomerID, t0.ContactName, t0.Phone, t0.City, t0.Country
    FROM Customers AS t0
  ) AS t1
  WHERE (t1.Country = 'UK')
) AS t2

为什么内层的查询要把外层从来没有用到过的数据给select出来？但愿数据库的优化做得够好，不要传输那些用不上或者没有必要返回到客户端的数据。但是，如果我们的查询翻译器能够自己消除这些重复的嵌套，将其转换为像一个真正的人类写出来的简单的形式的话，不是更好吗？这样，我们就可以写像下面一样复杂的查询了：

1
2
3
4
5
6
7
8
9

var query = from c in db.Customers
            join o in db.Orders on c.CustomerID equals o.CustomerID
            let m = c.Phone
            orderby c.City
            where c.Country == "UK"
            where m != "555-5555"
            select new { c.City, c.ContactName } into x
            where x.City == "London"
            select x;

我都不敢给你看这条查询会生成什么样的SQL了，因为我担心它会吓得你把电脑都关了。

接下来我就要告诉你我是如何挽起袖子写了些代码来拯救你的。其实也不是特别难。我原以为我们的代码会因为表达式树的不可变的特性而变得越来越复杂，因为order-by重写器似乎会很复杂，需要对表达式树进行的转换也越来越有趣。然而，我很惊喜地发现，我们清理多余的嵌套查询的逻辑实现起来却特别的简洁。

英文原文是Matt Warren发表在MSDN Blogs的系列文章之一，英文渣渣，翻译不供参考，请直接看原文。

距离上篇文章，又已经过了几个星期。我感觉大家可能已经迫不及待想要看到下篇文章了。你们的提供程序本来应该已经完成，可以拿到外面去惊艳众人，但是现在却放在角落里吃灰。

Implementing OrderBy

今天的话题是翻译order-by子句。幸运的是，进行排序操作的方式只有一种，那就是LINQ的排序操作符。但坏消息是，有四种不同的操作符。

使用查询的语法来写一条排序的查询是很简单的，只需一个子句就好。

1
2
3

var query = from c in db.Customers
            orderby c.Country, c.City
            select c;

但是，将上面的查询转换为方法调用的形式的话，所涉及到的就不止是一个LINQ操作符了。

1

var query = db.Customers.OrderBy(c => c.Country).ThenBy(c => c.City);

事实上，对于每个特定的排序表达式，都有它对应的排序操作符。因此LINQ提供程序在翻译SQL的时候，就需要将这些独立的操作符转换到一个单独的子句中。翻译这个的代码会比翻译之前的那些操作符的代码复杂一点，主要是因为需要先将这些独立的操作符全部找出来，才能对它们进行操作。之前的那些操作符可以简单地在前一个查询的外面套一个新的select，它们要考虑的只是当前操作符的那些参数。而排序不是，它还要考虑到其他的操作符。

首先，我们需要一种用来表示order-by子句的方式。最简单的方式是在已有的SelectExpression中加上一个描述排序的属性。但是，因为每个排序表达式都有一个排序方向，升序或降序，所以我需要把这些方向也保存下来。

所以，我添加了下面的新的定义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

internal enum OrderType {
    Ascending,
    Descending
}

internal class OrderExpression {
    OrderType orderType;
    Expression expression;
    internal OrderExpression(OrderType orderType, Expression expression) {
        this.orderType = orderType;
        this.expression = expression;
    }
    internal OrderType OrderType {
        get { return this.orderType; }
    }
    internal Expression Expression {
        get { return this.expression; }
    }
}

这个新的类型OrderExpression并不是一个真的Expression节点，因为我并不打算把它用在表达式树的任何位置，它只作为SelectExpression定义的一部分出现。因此SelectExpression也有一点小变化。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

internal class SelectExpression : Expression {
    ...
    ReadOnlyCollection<OrderExpression> orderBy;

    internal SelectExpression(
        Type type, string alias, IEnumerable<ColumnDeclaration> columns, 
        Expression from, Expression where, IEnumerable<OrderExpression> orderBy)
        : base((ExpressionType)DbExpressionType.Select, type) {
        ...
        this.orderBy = orderBy as ReadOnlyCollection<OrderExpression>;
        if (this.orderBy == null && orderBy != null) {
            this.orderBy = new List<OrderExpression>(orderBy).AsReadOnly();
        }
    }
    ...
    internal ReadOnlyCollection<OrderExpression> OrderBy {
        get { return this.orderBy; }
    }
}

当然，DbExpressionVisitor也需要一点小变化，以支持排序的功能。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

internal class DbExpressionVisitor : ExpressionVisitor {
    ...
    protected virtual Expression VisitSelect(SelectExpression select) {
        Expression from = this.VisitSource(select.From);
        Expression where = this.Visit(select.Where);
        ReadOnlyCollection<ColumnDeclaration> columns = this.VisitColumnDeclarations(select.Columns);
        ReadOnlyCollection<OrderExpression> orderBy = this.VisitOrderBy(select.OrderBy);
        if (from != select.From || where != select.Where || columns != select.Columns || orderBy != select.OrderBy) {
            return new SelectExpression(select.Type, select.Alias, columns, from, where, orderBy);
        }
        return select;
    }
    ...
    protected ReadOnlyCollection<OrderExpression> VisitOrderBy(ReadOnlyCollection<OrderExpression> expressions) {
        if (expressions != null) {
            List<OrderExpression> alternate = null;
            for (int i = 0, n = expressions.Count; i < n; i++) {
                OrderExpression expr = expressions[i];
                Expression e = this.Visit(expr.Expression);
                if (alternate == null && e != expr.Expression) {
                    alternate = expressions.Take(i).ToList();
                }
                if (alternate != null) {
                    alternate.Add(new OrderExpression(expr.OrderType, e));
                }
            }
            if (alternate != null) {
                return alternate.AsReadOnly();
            }
        }
        return expressions;
    }
}