gpt4 book ai didi

playframework-2.0 - 具有 SLICK 和 22 列限制的 Play Framework

转载 作者:行者123 更新时间:2023-12-01 01:06:59 24 4
gpt4 key购买 nike

我一直在对 Play 框架进行评估并学习 Scala,这很有趣。来自 Java,搬到 Scala 需要一些心理体操,但我现在是它的粉丝。

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

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

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

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

最佳答案

这种奇怪的编号限制很可能是因为 Scala 编程语言将元组的最大大小限制为 22,而元组是表示表行的好方法。见 Why are scala functions limited to 22 parameters?了解更多信息。有一些关于在 Scala 2.11(大概是在 Slick 中)中取消此限制的讨论,并且有 an open issue to track it ,但在最近的 2.11 版本中还没有发生这种情况。

我不是 Slick 开发人员,而且我确信他们可以基于没有限制的东西(例如 List 而不是元组)创建 ORM。这是我对为什么会这样的假设。

  • Typesafe 不想从头开始构建 ORM,因此改编自 ScalaQuery 的 Slick,它是 Scala 中最稳定和广泛采用的 ORM 包之一。
  • ScalaQuery 作者认为适合使用元组作为设计的关键部分。
  • ScalaQuery 作者觉得超过 22 列的表有点少见。
  • 他觉得那些拉出超过22列的表格的投影更加罕见。
  • Typesafe 正在努力消除元组(和函数)中的 22 限制,这对于 Scala 来说是必要的,一旦完成,Slick 将不再有 22+ 列表的问题。由于该问题必须在 Scala 中解决,因此这样做比创建新的 ORM 并与社区合作采用它更有意义。
  • 关于playframework-2.0 - 具有 SLICK 和 22 列限制的 Play Framework,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18048521/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com