【问题标题】:Playframework with SLICK and 22 column restriction具有 SLICK 和 22 列限制的 Playframework
【发布时间】:2013-08-05 14:11:05
【问题描述】:

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

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

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

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

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

【问题讨论】:

    标签: playframework-2.0 slick


    【解决方案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,ScalaQuery 是 scala 最稳定和广泛采用的 ORM 包之一。
    • ScalaQuery 作者认为使用元组作为设计的关键部分是合适的。
    • ScalaQuery 作者认为超过 22 列的表有些少见。
    • 他觉得那些超过 22 列的表格的投影更加罕见。
    • Typesafe 正在努力从元组(和函数)中删除 22 个限制,并且这样做对于 Scala 是必要的,一旦完成,Slick 将不再有 22+ 列表的问题。由于必须在 Scala 中解决该问题,因此这样做比创建新的 ORM 并与社区合作采用它更有意义。

    【讨论】:

    • 我完全意识到这一点,但我的问题是为什么要设计一个有这个限制的 ORM?例如。他们本可以像休眠一样使用反射。我认为他们不需要改变 Scala。
    • 啊,我不是很清楚你的问题。我更新了我对 Slick 中出现此限制的原因的猜测。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2013-12-31
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多