7

I use Slick 1.0.0-RC1. I have this definition for table object:

object ProductTable extends Table[(Int, String, String, String, Double, java.sql.Date, Int, Option[Int], Int, Boolean)]("products") {
  def id = column[Int]("productId", O.PrimaryKey, O.AutoInc)
  def title = column[String]("title")
  def description = column[String]("description")
  def shortDescription = column[String]("shortDescription")
  def price = column[Double]("price")
  def addedDate = column[java.sql.Date]("addedDate")
  def brandId = column[Int]("brandId")
  def defaultImageId = column[Option[Int]]("defaultImageId")
  def visitCounter = column[Int]("visitCounter")
  def archived = column[Boolean]("archived")
  def * = id ~ title ~ description ~ shortDescription ~ price ~ addedDate ~ brandId ~ defaultImageId ~ visitCounter ~ archived
}

I need a simple query which selects 8 rows from database:

ProductTable.filter(_.title === "something")
  .sortBy(_.visitCounter)
  .map(_.title)
  .take(8)
  .selectStatement

And the output is:

select x2.x3 from 
   (select x4.`title` as x3 from `products` x4 
     where x4.`title` = 'something' 
     order by x4.`visitCounter` limit 8) x2

If I get rid of take() method:

ProductTable.filter(_.title === "something")
 .sortBy(_.visitCounter)
 .map(_.title)
 .selectStatement

then the output is:

select x2.`title` from `products` x2 
where x2.`title` = 'something' 
order by x2.`visitCounter`

So my question is: Why does Slick generate a subquery when its query object is constructed with take() method?

P.S. If it can be related, I use MySql driver with all of these

4

1 回答 1

12

有一个简短的答案和一个长的答案。简短的是：子查询在那里，因为到目前为止没有人费心去删除它。

更长的答案与交换“map”和“take”没有任何区别的事实有关，这是因为查询的编译几乎是简单而直接的。

在查询编译器的相对较早的阶段，有一个“forceOuterBinds”阶段，它（可能）引入了许多在语义上等效且冗余的额外 Bind（又名 flatMap）操作。这个想法是获取一些具有集合类型的x并将其转换为Bind(s, x, Pure(s))，其中s是一个新的符号。如果x已经是Pure(y)的形状，我们将其转换为Bind(s, Pure(ProductNode()), Pure(y))。在 Scala 代码中，将其视为将x: List[T]转换为x.flatMap(s => List(s))或将List(y)转换为List(()).flatMap(s => List(y )). 这种转换的目的是通过给我们一个地方来修改我们可能想要做的所有地方的投影（它是作为恒等映射创建的），从而使后面的编译器阶段中的树重写更容易。

稍后，在“convertToComprehensions”中，monadic 形式的所有节点（Bind、Pure、Filter、Take、Drop 等）都被单独转换为 Comprehension 节点（表示 SQL选择语句）。结果仍然不是合法的 SQL：SQL 推导不是 monad 推导。它们具有非常有限的范围规则，不允许from子句引用由前一个from子句引入的变量（在相同的理解或封闭理解中）。

这就是为什么我们需要下一个阶段，“fuseComprehensions”，乍一看可能纯粹是一种优化，但实际上是生成正确代码所必需的。这个阶段试图尽可能地融合个人理解，以避免这些非法引用。我们已经在可以融合的方面取得了一些进展，但范围问题的 100% 解决方案还遥遥无期（事实上，我很确定这是不可能解决的）。

重申一下，这一阶段的进步主要是出于对正确性的需求，而不仅仅是生成更好的代码。那么我们可以删除那个额外的子查询吗？是的，当然，但还没有人实施它。

如果你想尝试实现这样的优化，这里有一些注意事项需要考虑：

  • 您是否满足于删除纯粹的混叠投影（即选择槽的形式为 Some(ProductNode(ch)) 的理解，其中 ch 的每个元素都是路径）？
  • 或者也许你认为select x+1 from (... limit ...))也应该被融合。你可以允许什么样的表达方式？例如，RowNum 可以吗？
  • 子查询需要有什么样的形状？例如，它可能包含groupBy或orderBy子句吗？

（还有一些事情让我思考：与解释为什么它还不存在相比，实现该优化需要多长时间？）

于 2013-01-23T15:36:04.807 回答