Playframework与SLICK和22列限制

Question

Playframework与SLICK和22列限制

4

我一直在评估Play框架并学习Scala，这很有趣。从Java转向Scala需要做出相当大的努力，但现在我已经成为它的粉丝。

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

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

我看到了对此的解决方法，需要拆分情况类并使用隐式转换重新组合。但这只是一个hack。

我猜如果我想继续使用Play，那我应该转到Java并使用JPA。

- Andrew Wheeler

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- lreeder · Accepted Answer

这个奇怪的数字限制最有可能是因为 Scala 编程语言限制元组的最大大小为 22，并且元组是一种表示表行的好方法。详见为什么 Scala 函数只限制 22 个参数？获得更多信息。据说在 Scala 2.11（以及 Slick）中已经有一些讨论关于取消这个限制，而且有一个开放问题可以跟踪它，但是这在最近的 2.11 版本中还没有发生。

我不是 Slick 开发人员，我相信他们可以创建基于类似 List 而非元组等限制的 ORM。以下是我为什么认为会这样的假设：

Typesafe 不想从头开始构建 ORM，所以从 ScalaQuery 中调整 Slick，ScalaQuery 是 Scala 中最稳定、最广泛采用的 ORM 包之一。
ScalaQuery 的作者认为将元组作为设计的关键部分是恰当的。
ScalaQuery 的作者觉得拥有超过 22 列的表有点罕见。
他觉得选择那些拉取超过 22 列的表的投影甚至更罕见。
Typesafe 正在努力从元组（和函数）中除去 22 个限制，这对于 Scala 是必要的。一旦完成这个目标，Slick 将不再有处理 22+ 列表的问题。由于问题必须在 Scala 中解决，因此最好这样做，而不是创建一个新的 ORM 并与社区合作采用它。