Stefan Zeiger

Technically, you're both right. It is written as a join, so it appears to be deleting "from multiple tables" for Slick, but it really only deletes from one. The workaround...

Marking this issue for use in the planned documentation improvements in 3.2. Just a quick comment about composition at this point: The distinction between methods that can be composed in...

Could be a different issue. According to https://github.com/slick/slick/blob/master/slick-testkit/src/main/scala/com/typesafe/slick/testkit/tests/JdbcMiscTest.scala#L37-L51 `setFetchSize` is called with the correct value.

I need to investigate this further. Off the top of my head I have no idea why it doesn't work. I was merely pointing out that we do have a...

@gaydenko Did you have a chance to test this in 3.0? There have been little changes in this regard so I would expect the bug to be already present in...

I just noticed a difference. Your JDBC code has `conn.setAutoCommit(false)` but the Slick code runs in auto-commit mode. Does it behave differently with `.transactionally`?

Assigning to 3.2. We should either document these idiosyncrasies or make the desirable behavior the default (maybe with a config option to turn it off and use the JDBC driver's...

`transactionally` enforces that the code runs on a single `Connection` with with `setAutoCommit(false)`. Everything else depends on the JDBC parameters like `ResultSetConcurrency` and `ResultSetHoldability`.

Fixing the deadlock problem was the priority for 3.2. Now that this is done I will get back to the other open PRs for 3.2.1/3.3.

3.1 produces a single comprehension in this case because it removes the subqueries for the nested tables and fuses the join (with a join condition) and the filter into a...