减少案例类模型的 Slick 定义中的样板答案

【问题标题】：Reducing boilerplate in Slick definitions for case class models减少案例类模型的 Slick 定义中的样板
【发布时间】：2015-12-02 20:27:31
【问题描述】：

在学习 play-slick 并设置最终保存到 PostgreSQL 的模型类时，我看到了这种模式（代码如下）。有一个简单的案例类充当模型，然后是扩展 Table 的东西来处理关系映射。

case class Cat(name: String, color: String)

/* Table mapping
 */
class CatsTable(tag: Tag) extends Table[Cat](tag, "CAT") {

  def name = column[String]("name", O.PrimaryKey)
  def color = column[String]("color", O.NotNull)

  def * = (name, color) <> (Cat.tupled, Cat.unapply _)
}

在许多常见情况下，这让我觉得是一堆不必要的样板，但我只是在学习，所以我不知道我在这里缺少什么。有没有更简单的方法从case class Cat 开始并最终得到一个我可以用于数据库中Cat CRUD 实例的对象？例如。似乎没有必要指定String 类型的属性最终应该是column[String]，等等。在其他框架中，我可能必须添加注释或其他内容来指示我想成为主键或不可为空，但我不会真正编写单独的映射。通过手写这些映射，我主要是花费更多时间，并有机会以微妙的方式将其搞砸，以应对原本简单的情况。

我最理想的做法是从case class Cat 开始，在上面撒上魔法框架的灰尘，然后得到一个具有合理默认值的CatsTable，我可以根据需要覆盖/自定义。

当我搜索这方面的文档时，我通常会回到schema code generation，但这似乎倒退了；我不想从现有/填充的 RDBMS 生成表映射，我想从头开始。

【问题讨论】：

有点晚了，但另一个库是http://getquill.io/，它比 Slick 需要更少的样板，并且还提供了 jdbc 或真正异步 db 调用的选择。截至 2017 年 6 月，它感觉不太完善 - 例如，我目前正在使用 Slick 和 Quill 的组合，因为我无法让后者调用存储过程。

标签： scala playframework slick

【解决方案1】：

对于这个问题的未来搜索者，这是我发现的：

你不能减少样板，它必须在那里。 Slick 有一个code generation 功能，但并不完全相同。如果你有一个 SQL 模式，它会为你生成表映射。

现在，您可能会问，如果它可以自动为您生成表映射，那您为什么还要编写它们并维护它呢？看来答案是可以在编译时加载类型定义。当然，它们可以生成，但它们不会是“类型安全的”，因为编译器不会在编译时没有实际代码的情况下检查你的代码。

所以这似乎取决于这一层类型安全的感知价值。如果您认为有必要，则此代码不是样板代码。如果您认为此特定层的类型安全并非绝对必要，那么这确实是样板。

这似乎归结为更大的 FP 假设，即类型安全始终很重要，对我来说，这是一个“纯粹”论点的结尾。

【讨论】：