具有SLICK和22列限制的Playframework

Question

我一直在评估Play框架并学习Scala，这很有趣。来自Java，转移到Scala花了很多心理体操，但我现在是粉丝。

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

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

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

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

Answer 1

这个奇怪的编号限制很可能是因为Scala编程语言将元组的最大大小限制为22，而元组是表示表行的好方法。有关详细信息，请参阅Why are scala functions limited to 22 parameters?。有一些关于在Scala 2.11中删除此限制的讨论（并且可能在Slick中），并且有an open issue to track it，但是在最近的2.11版本中没有发生这种情况。

我不是Slick的开发人员，我确信他们可以创建一个基于没有像List而不是Tuples这样的限制的ORM。以下是我为什么会这样做的假设。

• Typesafe不想从头开始构建ORM，因此ScalaQuery改编了Slick，这是scala最稳定和广泛采用的ORM包之一。
• ScalaQuery作者认为使用元组作为设计的关键部分是合适的。
• ScalaQuery作者觉得有超过22列的表格有点罕见。
• 他觉得那些拉超过22列的桌子的投影更为罕见。
• Typesafe正在努力从Tuples（和函数）中删除22限制，并且这对Scala来说是必要的，一旦完成，Slick将不再有22个以上列表的问题。由于必须在Scala中修复此问题，因此创建新ORM并与社区合作采用它更有意义。