plain slick api 使用问题记录

[timzaak]

GetResult r.<< 和表顺序一致，导致如果case class里Field的顺序和表顺序不一致会产生运行时异常。

不使用 select * 这种语句。需要将 case class field name 放进去。目前 Dao 层 DSL 已经实现。

无法简单安全封装像 pagination 这样的方法

如果封装，需要费大工夫，那还不如使用其他的一些框架呢

skinny-framwork orm 或许可以看看。

[timzaak]

where in 这种语法，如果是 string 还好说，但是 Int, Long 的时候，就有问题了。下面是 hack 方案： https://stackoverflow.com/questions/31156613/is-it-possible-to-use-in-clause-in-plain-sql-slick-for-integers

[timzaak]

当 sql 语句中 包含 ? 时，要转义 ??

[timzaak]

关于 db 句柄和相关隐士转换的处理：

我们一般会在 service 层事务，这就导致一些在 dao 层用的辅助 API 以及 sql 语句构造，在 service 层也需要用到。

所以，辅助 api 要与 dao 脱离出来，方便 service 层处理。 dao 层要给 service 层提供 sql 构造器，方便执行。

这个地方会牵扯以后的分库分表，应该通过中间件去做事务。然后尽量不用关联查询

[timzaak]

case class AB()
implicit val a = MappedColumnType.base[AB, String]( ab=> "", str => AB())

数据类型隐式转换。。 方便 table 描述。

[timzaak]

使用总结

由于目前所在公司使用的是 slick functional mapping program. 所以对 slick 有一个更全面的了解了。 目前对其使用方式是：

• 建表还是要用 Tables API
• 插入数据 functional mapping program
• 查找用 functional mapping api, 在复杂多表的情况下，还真不如 plain sql 来的省事
• 开发的时候，打开 sql 日志开关，遇到复杂 sql ，更应该多看看 slick 到底吐出来的是什么
• db 句柄需要放到 service 层，为事务开道，否则鬼知道程序员是否会因为找不到db，就不写事务了。
• 大批量处理用 jdbc api，没错的

最后，能用 slick functional 就用它，用不了再换 plain sql。 目前代码中 plain sql 最终需要迁移的。

[timzaak]

最后的最后。选型为 skinny-framwork orm