1

我正在使用 Play 2.1.1、Postgress 和 Herkou，并且只从我的生产数据库中获得奇怪的异常。

在本地与 H2 相比，一切正常。然而，在生产中，相同的操作失败了：

2013-06-14T01:49:25.275717+00:00 app[web.1]: [←[37minfo←[0m] application - 2013-06-14T01:49:25.275Z - Updating cache with new peak 266
2013-06-14T01:49:48.310600+00:00 app[web.1]: [←[37minfo←[0m] application - Updating database with peak 266
2013-06-14T01:49:48.327490+00:00 app[web.1]: [←[31merror←[0m] application -
2013-06-14T01:49:48.327490+00:00 app[web.1]:
2013-06-14T01:49:48.327490+00:00 app[web.1]: ! @6eih9flgb - Internal server error, for (GET) [/updateDB] ->
2013-06-14T01:49:48.327490+00:00 app[web.1]:
2013-06-14T01:49:48.327490+00:00 app[web.1]: play.api.Application$$anon$1: Execution exception[[RuntimeException: TypeDoesNotMatch(Cannot convert 266:
class java.math.BigDecimal to Long for column ColumnName(peaks.price,Some(price)))]]
2013-06-14T01:49:48.327490+00:00 app[web.1]:    at play.api.Application$class.handleError(Application.scala:289) ~[play_2.10-2.1.0.jar:2.1.0]
2013-06-14T01:49:48.327490+00:00 app[web.1]:    at play.api.DefaultApplication.handleError(Application.scala:383) [play_2.10-2.1.0.jar:2.1.0]
2013-06-14T01:49:48.327490+00:00 app[web.1]:    at play.core.server.netty.PlayDefaultUpstreamHandler$$anonfun$12$$anonfun$apply$24.apply(PlayDefaultUp
streamHandler.scala:314) [play_2.10-2.1.0.jar:2.1.0]
2013-06-14T01:49:48.327490+00:00 app[web.1]:    at play.core.server.netty.PlayDefaultUpstreamHandler$$anonfun$12$$anonfun$apply$24.apply(PlayDefaultUp
streamHandler.scala:312) [play_2.10-2.1.0.jar:2.1.0]
2013-06-14T01:49:48.327490+00:00 app[web.1]:    at play.api.libs.concurrent.PlayPromise$$anonfun$extend1$1.apply(Promise.scala:113) [play_2.10-2.1.0.j
ar:2.1.0]
2013-06-14T01:49:48.327660+00:00 app[web.1]:    at play.api.libs.concurrent.PlayPromise$$anonfun$extend1$1.apply(Promise.scala:113) [play_2.10-2.1.0.j
ar:2.1.0]
2013-06-14T01:49:48.327660+00:00 app[web.1]: java.lang.RuntimeException: TypeDoesNotMatch(Cannot convert 266:class java.math.BigDecimal to Long for co
lumn ColumnName(peaks.price,Some(price)))
2013-06-14T01:49:48.322664+00:00 heroku[router]: at=info method=GET path=/updateDB host=www.bitcoinpeak.org fwd="84.94.173.221" dyno=web.1 connect=2ms
 service=2019ms status=500 bytes=1941
2013-06-14T01:49:48.327660+00:00 app[web.1]:    at scala.sys.package$.error(package.scala:27) ~[scala-library.jar:na]
2013-06-14T01:49:48.327660+00:00 app[web.1]:    at anorm.Sql$.as(Anorm.scala:535) ~[anorm_2.10-2.1.0.jar:2.1.0]
2013-06-14T01:49:48.327660+00:00 app[web.1]:    at anorm.Sql$class.executeInsert(Anorm.scala:474) ~[anorm_2.10-2.1.0.jar:2.1.0]
2013-06-14T01:49:48.327660+00:00 app[web.1]:    at anorm.SimpleSql.executeInsert(Anorm.scala:370) ~[anorm_2.10-2.1.0.jar:2.1.0]
2013-06-14T01:49:48.327660+00:00 app[web.1]:    at org.bitcoinpeak.Peak$$anonfun$addPeak$1.apply(Peak.scala:43) ~[bitcoin-peak_2.10-1.0-SNAPSHOT.jar:1
.0-SNAPSHOT]
2013-06-14T01:49:48.327660+00:00 app[web.1]:    at org.bitcoinpeak.Peak$$anonfun$addPeak$1.apply(Peak.scala:40) ~[bitcoin-peak_2.10-1.0-SNAPSHOT.jar:1
.0-SNAPSHOT]
2013-06-14T01:50:24.933750+00:00 app[web.1]: [←[37minfo←[0m] application - 2013-06-14T01:50:24.933Z - Updating cache with new peak 266
2013-06-14T01:51:24.796588+00:00 app[web.1]: [←[37minfo←[0m] application - 2013-06-14T01:51:24.796Z - Updating cache with new peak 266
2013-06-14T01:51:40.719105+00:00 heroku[router]: at=info method=HEAD path=/ host=www.bitcoinpeak.org fwd="74.86.158.106" dyno=web.1 connect=1ms servic
e=7ms status=404 bytes=1900
2013-06-14T01:52:25.047381+00:00 app[web.1]: [←[37minfo←[0m] application - 2013-06-14T01:52:25.047Z - Updating cache with new peak 266
2013-06-14T01:52:33.646553+00:00 heroku[router]: at=info method=GET path=/ host=www.bitcoinpeak.org fwd="74.86.158.107" dyno=web.1 connect=2ms service
=21ms status=200 bytes=1892
2013-06-14T01:53:25.420489+00:00 app[web.1]: [←[37minfo←[0m] application - 2013-06-14T01:53:25.420Z - Updating cache with new peak 266

这是生产表的样子：

> \d+ Peaks
                                         Table "public.peaks"
 Column |            Type             |       Modifiers        | Storage | Stats target | Description
--------+-----------------------------+------------------------+---------+--------------+-------------
 price  | numeric(20,0)               | not null               | main    |              |
 time   | timestamp without time zone | not null default now() | plain   |              |

为什么在本地工作的相同代码在生产中失败？是 SQL 的味道吗？我该如何解决？

奇怪的是，我正在尝试执行的事务（插入一行）确实有效 - 添加了该行。那么异常从何而来？

如果有人需要更多上下文，整个项目就是一个 github 。

更新：案例类：

import java.math.BigDecimal
import org.joda.time.DateTime

case class Peak(
  time: DateTime,
  price: BigDecimal
)
4

3 回答 3

1

我在使用不同的数据库系统时看到了类似的问题。因此，我建议您检查您的数据库版本、配置、表的 DDL 以及用于使列在一种情况下显示为 BigDecimal 而在另一种情况下显示为 Long 的细微差异的确切 JDBC 驱动程序。

您可能还想查看这张票： http: //play.lighthouseapp.com/projects/82401/tickets/243-weird-typedoesnotmatch-exception-in-rc-3-and-final

列的顺序和某些版本的播放似乎存在问题。

于 2013-06-14T06:25:24.723 回答
0

在 app/helpers 文件夹中创建 AnormExtension 助手。称它为 AnormExtension.scala。代码如下。此外，最好将 BigDecimal 转换为 Double 而不是 Long。

仅供参考 - 请注意，我不会尝试转换为 Scala BigDecimal。Scala BigDecimal 是一个谜。我会不管它。

object AnormExtension {

 implicit def rowToDouble: Column[Double] = Column.nonNull { (value, meta) =>
   val MetaDataItem(qualified, nullable, clazz) = meta
     value match {
       case d: java.math.BigDecimal => Right(d.doubleValue())
       case _ => Left(TypeDoesNotMatch("Cannot convert " + value + ":" + value.asInstanceOf[AnyRef].getClass + " to Double for column " + qualified))
     }
 }
}
于 2014-08-06T05:24:49.423 回答
0

很抱歉回答迟了，但如果其他人偶然发现这个问题并在 SO 上搜索，我会回复。

在您的情况下，您的 JDBC 驱动程序返回的Long数据类型似乎是使用 H2 驱动程序时返回的数据类型，以及BigDecimal使用 Postgres 驱动程序时返回的数据类型。此行为可能取决于驱动程序实现以及数据库如何决定使用 JDBC 将其数据库数据类型转换为 Java 类型。在 H2 的情况下，它用 a 来做，Long你很好。对于 Postgres，它决定返回 a BigDecimal。

有一个类似的问题，尽管在此链接中描述了不同的根本原因。有一个提供的解决方案应该适合您使用 into 的隐式转换Column[BigInt]，Column[Long]但我们将转换 from Column[BigDecimal]into Column[Long]：

implicit def rowToLong: Column[Long] = Column.nonNull { (value, meta) =>
  val MetaDataItem(qualified, nullable, clazz) = meta
    value match {
      case int: Int => Right(int: Long)
      case long: Long => Right(long)
      case bd:BigDecimal => Right(bd.longValue())  //Handle BigDecimal correctly
      case _ => Left(TypeDoesNotMatch("Cannot convert " + value + ":" + value.asInstanceOf[AnyRef].getClass + " to Long for column " + qualified))
    }
}

这应该转换为类型LonganyBigDecimal或。这几乎与 Anorm类中的原始 Scala 代码相同，只是增加了处理！LongintColumnBigDecimal

在这个（被拒绝的）拉取请求中还有一些更进化的隐式转换。值得注意的是，这些更改被拒绝是因为这些额外的隐式转换的行为是不确定的，考虑到修复取决于正在使用的 JDBC 驱动程序以及可能是哪个版本。最重要的是，这是修改数据的神奇行为。因此，不幸的是，用户应该对这些更改负责。小心应用此修复程序，并确保它与您的所有环境和数据良好交互。

于 2014-02-03T23:55:41.123 回答