mysql - 原始 SQL 查询中多种类型的 Scala Slick 隐式转换

Question

我正在开发一个 Scala Play Framework 2.2 项目，我使用 play-slick 0.5.0.8 作为我的数据库访问层。

我的一个 DAO 对象中有以下代码:

def randomByBlahAndDate(blah: Blah, newerThan: LocalDate)(implicit s: Session): Option[Photo] = {
  sql"select * from photos where blah = $blah and imgDate > $newerThan order by rand()".as[Photo].headOption
}

如您所见，它做了一些棘手的事情，例如通过 rand() 进行排序，这就是我决定采用原始 SQL 路线的原因。无论如何，我在编译时遇到以下错误:

could not find implicit value for parameter pconv: scala.slick.jdbc.SetParameter[(models.Blah.Blah, org.joda.time.LocalDate)]

看起来好像 slick 正在尝试将我的两种类型作为一个集合一起转换......很奇怪。我的 Blah 枚举有一个隐式类型转换器，它在插入和获取 Photo 对象时正常工作:

def enumToStringMapper(enum: Enumeration) = MappedTypeMapper.base[enum.Value, String](
enum   => enum.toString,
string => enum.withName(string))

implicit val FormatMapper = enumToStringMapper(Blah)

我还导入 com.github.tototoshi.slick.JodaSupport._ 以支持 LocalDate 转换。这在插入和获取 Photo 对象时也能正常工作。

有什么想法吗？也许某种更好的查询机制可以支持我的需求(枚举相等性、日期比较和 rand() 排序)？谢谢。

更新:2013-10-27

我现在正在尝试执行以下操作，但没有成功:

def recordGuess(date: LocalDate, correctBlah: Blah, incorrectBlah: Blah, isCorrect: Boolean)(implicit s: Session) {
  val correctIncrement = if(isCorrect) 1L else 0L
  sqlu"insert into stats (date, correctBlah, incorrectBlah, impressions, guesses, correct) values ($date, $correctBlah, $incorrectBlah, 1, 1, $correctIncrement) on duplicate key update guesses = guesses + 1, correct = correct + $correctIncrement".first
}

同样，这不起作用:

could not find implicit value for parameter pconv: scala.slick.jdbc.SetParameter[(org.joda.time.LocalDate, models.Blah.Blah, models.Blah.Blah)]

但是，这次我看不出有什么好的、简单的解决方法。似乎 Typesafe 的 sql 和 slick 中的 sqlu 不支持隐式转换。

Answer 1

我还没有找到隐式转换问题的解决方案，但我找到了一个使用更传统的巧妙语法和 scala.util.Random.shuffle 的解决方法:

def randomByBlahAndDate(blah: Blah, newerThan: LocalDate)(implicit s: Session): Option[Photo] = {
  val photos = Query(Photos).where(_.imgDate > newerThan).where(_.blah === blah).run
  val r = new scala.util.Random(scala.compat.Platform.currentTime)
  r.shuffle(photos).headOption
}

与使用 MySQL 的 rand() 相比，我不确定效率如何，但这暂时可以。