【问题标题】:Play anorm 2.3 - 2.4 migrationPlay anorm 2.3 - 2.4 迁移
【发布时间】:2015-10-08 09:23:07
【问题描述】:

在迁移到 play 2.4 时,我注意到以下几点:

1/apply 在 SqlQuery 上已弃用 - 好的 - 我查看了提供的实现:

def go(c: Option[Cursor], s: Stream[Row]): Stream[Row] = c match {
      case Some(cursor) => go(cursor.next, s :+ cursor.row)
      case _ => s
    }

这不是将每个元素附加到时间与流大小成正比的 Stream 吗?例如,那最终不是 n2 吗?我认为以前的实现使用了缺点......

2/SqlQuery("qry") 曾经有办法不解析查询 - 这似乎已被删除

我有一个经常执行查询的用例(例如 1000qps)并且我无法缓存一次:它看起来像 select X,Y,Y from dbname.db - 所以没有可绑定的数据库名称语句。对于大型查询,事实证明语句解析器有点慢 - 有没有办法明确地说:我不需要解析该查询?

3/ResultSetParser 已完全私有化 - 我有一个 util 函数,它提供:

def vector[A](p: RowParser[A]): ResultSetParser[Vector[A]] ...

因为我更喜欢 Vector - 我将它与 SQL("...").as 一起使用 关于如何更换的任何建议? withResult 可能吗?

【问题讨论】:

标签: playframework anorm


【解决方案1】:

1..apply 的当前实现仅用于向后兼容,已弃用。如果你想做流媒体,你可以看看流媒体支持:.withResult.foldWhile

2. 不再允许直接构造底层查询类型 (SqlQuery),因为它会绕过在使用公共构造函数 SQL(...)(或 SQL 插值 SQL"..." )。没有什么能阻止以这种方式初始化查询以通过不同的参数重新使用它。

val baseQuery = SQL("SELECT * FROM Test WHERE id = {id}")
val query1 = baseQuery.on("id" -> "foo")
val query2 = baseQuery.on("id" -> "bar")

3. 正如问题跟踪器中所说,ResultSetParser 并非设计为通用类型,而是用于 Anorm 实现的内部使用。打开它会影响维护。

您可以从List.*.+ 解析器)获取Vector,或者使用流式支持自行构建向量,无需中间列表。

【讨论】:

  • 请保持建设性并阅读文档。 1 Play 的向后兼容性要求该功能仍然存在,即使您认为它不是最理想的。您可以免费使用新的 Streaming 支持,也可以讨论 MailingList 的改进。 2。如前所述,没有什么可以阻止从SQL 准备查询,以使用不同的参数集多次运行它。顺便说一句,为了提高性能,SQL 插值是在 2.3 中引入的。
  • 嗨 - 抱歉并不是说不具有建设性 - 我仍然是 scala 世界中最好的 SQL 库的异常粉丝!!- 虽然我认为当前的 apply 实现可能会导致无法预料的性能。 prod 服务器中的问题,如果超过大型结果集。我确实放弃了它并切换到 withResult - 至于 SQL 插值,就像我说我对它的性能很满意,它更适合我的特定用例......
猜你喜欢
  • 2016-12-21
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-06-19
  • 2014-08-13
  • 1970-01-01
相关资源
最近更新 更多