4

我一直在评估 Play 框架并学习 Scala，这很有趣。来自 java，迁移到 Scala 需要相当多的精神体操，但我现在是一个粉丝。

我已经使用 JPA 映射了一个相当大的数据库，我打算继续使用这段代码（使用休眠），但这不是 Scala 的最佳或推荐方法。所以我开始使用 SLICK 映射一些表，但在走得太远之前，我意识到我会遇到 Scala 对案例类和函数参数的限制（不超过 22 个）的问题。

我发现现代 ORM 会有这种限制，这完全令人困惑。我对 Scala 有这个限制没有问题——毕竟谁想将 22 个参数传递给一个函数。所以我的问题是：为什么要设计一个有这个限制的库？当然它应该被设计为映射到常规类？我不在乎它是否甚至使用反射来完成工作。

我已经看到了需要拆分案例类并使用隐式转换重新组合的解决方法。但这只是一个黑客。

我想如果我想继续使用 Play，那么我应该切换到 Java 并使用 JPA。

4

1 回答 1

4

这个奇怪的编号限制很可能是因为 Scala 编程语言将元组的最大大小限制为 22，而元组是表示表行的好方法。请参阅为什么 scala 函数仅限于 22 个参数？了解更多信息。在 Scala 2.11 中（可能是在 Slick 中）中已经有一些关于删除此限制的讨论，并且有一个未解决的问题来跟踪它，但这在最近的 2.11 版本中还没有发生。

我不是一个 Slick 开发人员，我相信他们可以基于没有限制的东西创建一个 ORM，比如 List 而不是 Tuples。这是我的假设，为什么结果会这样。

  • Typesafe 不想从头开始构建 ORM，因此从 ScalaQuery 改编了 Slick，ScalaQuery 是 scala 最稳定和广泛采用的 ORM 包之一。
  • ScalaQuery 作者认为使用元组作为设计的关键部分是合适的。
  • ScalaQuery 的作者觉得超过 22 列的表有点少见。
  • 他觉得那些拉动超过 22 列的表格的投影更加罕见。
  • Typesafe 正在努力从元组（和函数）中删除 22 个限制，并且这样做对于 Scala 是必要的，一旦完成，Slick 将不再有 22+ 列表的问题。由于必须在 Scala 中解决该问题，因此这样做比创建新的 ORM 并与社区合作采用它更有意义。
于 2013-08-05T03:29:47.377 回答