slick/slick — pull request #197 by szeiger (2013-08-20 11:53:14+00:00)
Title: Implement the new column expansion and flattening scheme.

As a follow-up to https://github.com/slick/slick/pull/185, here is the new column flattening.

This is a complete rewrite and redesign of the central phases of the
query compiler. The new drill is:

- expandTables: The old algorithm expanded tables into their star
projection at the place where a table was introduced, and then
propagated the necessary values outwards. But a table's star
projection is only relevant for the client side, so there is only one
place where we expand it in the new scheme: At the outermost layer of
a query in its return value. Since we know the query's result type, we
can simply take all the NominalTypes with TableIdentitySymbols in that
type, find the matching TableExpansions in the tree and wrap the whole
tree in a mapping operation that copies the return value (purely based
on its type), expanding the tables in it.

- expandRecords: Expand paths to ProductNodes and StructNodes into
ProductNodes and StructNodes of paths, preserving the types and the
paths into the expanded structure.

- flattenProjections: Bring all Pure nodes into a Pure(StructNode) form
where the StructNode children are individual columns.

- relabelUnions: Still the old implementation. It should be possible to
write a simpler type-aware version.

- pruneFields: Remove unreferenced fields from the Pure(StructNode))
nodes created earlier. If such a Pure's TypeSymbol is not referenced
at all (i.e. it occurs at the outer layer below the ResultSetMapping
or inside an aggregation function), change it to a ProductNode or an
individual column.

The assignUniqueSymbols phase is also extended to assign unique identity
TypeSymbols for TableNode and Pure nodes in addition to replacing term
symbols.

convertToComprehensions is modified to introduce identity mappings for
all TableNodes because the old comprehension fusion algorithm relies on
this shape but the new column flattening no longer produces these
extraneous mappings.

Review by @cvogt