Slick 2.0.0-M3 released

[Stefan Zeiger]

Hello,

We have just released Slick 2.0.0-M3, the third milestone for Slick 2.0. It should show up on Maven Central within the next few hours. You can find the source code here: https://github.com/slick/slick/tree/2.0.0-M3. Please see http://slick.typesafe.com/docs/ for documentation.

We published M2 in July but it was never officially announced and did not come with updated documentation, so these release notes include the changes for both, M2 and M3.

These are the major new features added since M1:

• Table definitions in the Lifted Embedding use a new syntax which is slightly more verbose but also more robust and logical, avoiding several pitfalls from earlier versions.

• Table definitions (and their * projections) are not restricted to flat tuples of columns anymore. They can use any type that would be valid as the return type of a Query. The old projection concatenation methods ~ and ~: are still supported but not imported by default.

• In addition to Scala tuples, Slick supports its own HList abstraction for records of arbitrary size. You can also add support for your own record types with only a few lines of code. All record types can be used everywhere (including table definitions and mapped projections) and they can be mixed and nested arbitrarily.

• Some changes to the API to bring it closer to Scala Collections syntax.

• threadLocalSession has been renamed to dynamicSession and the corresponding methods have distinct names (e.g. withDynSession vs the standard withSession). This allows the use of the standard methods without extra type annotations. Thread-local sessions are not deprecated but we want to push explicit session management (with the now simpler syntax) as the default.

• Some important parts of the query compiler have been rewritten. Column flattening and the emulation of Boolean which is required by some databases should now be more robust.

• Soft inserts are now the default, i.e. AutoInc columns are automatically skipped when inserting with +=, ++=, insert and insertAll. This means that you no longer need separate projections (without the primary key) for inserts. There are separate methods forceInsert and forceInsertAll in JdbcProfile for the old behavior.

• A new model for pre-compiled queries replaces the old QueryTemplate abstraction. Any query (both, actual collection-valued Query objects and scalar queries) or function from Column types to such a query can now be lifted into a Compiled wrapper. Lifted functions can be applied (without having to recompile the query), and you can use both monadic composition of Compiled values or just get the underlying query and use that for further composition.

Note that this is not a production-ready or beta release. The Slick Extensions package is not available for this milestone release and the Slick Examples and Slick Testkit Example projects have not been updated yet.

We expect that the next published version of Slick will be 2.0.0-RC1 which will integrate code-generator-based type providers and add more documentation and bug fixes. It will also come with an updated Slick Extensions package.

Here is a complete list of changes since M1:

• b70a2c7 Update build for 2.0.0-M3
• 1c488ea Deprecate notIn, add filterNot for orthogonality and conformity with Scala collections see https://github.com/slick/slick/pull/204
• d1849b8 Add a separate compiler phase for boolean emulation.
• 32e8cee bumped scala to 2.10.3, sbt to 0.13.0, mima to 0.1.6
• 24b0ed7 Fix existing doctests, execute all doctests (including required fixes)
• 2a4d156 Fix fusion of Take and Drop operators.
• 3464b5e Fix compilation error introduced by merging #232 and #243 together.
• 48f0648 Add test case for multi-level mapping with <>, prompted by issue #78.
• c2eb8da Add createDDLInvoker (similar to createInsertInvoker).
• c897ad9 Add HList and Nat implementations with Shapes for the HList.
• d6428b7 Simplify custom Shape definitions
• 99f19fc Use bind variables for types which do not support literals.
• 68996f0 Skip AutoInc columns by default when inserting data.
• bda93a7 Introduce “Compiled” computations to replace parameterized queries.
• 4ee1c5c Treat Unit as an empty product type.
• bbf9694 Add a common abstraction for literal and parameter columns.
• b8eaa59 Improve Shape encoding to support Columns-level Shapes.
• 942d98f Add a nested Shape for Queries.
• f16915d Allow unit tests which assure that some code does not type-check.
• ff992bb Add Shape levels to differentiate between flat and nested Shapes.
• e9d6f69 Running a query to match a specific UUID in MySQL fails in 1.0.1. For example, the following code will fail with error “UUID does not support a literal representation”.
• 1c1bf30 Fuse simple mappings before resolving GroupBy.
• 009dc35 Flatten nested ProductNodes in GroupBy keys.
• 01410cd Use fixed version numbers for fmpp’s dependencies.
• d054bf5 Rename .elements to .iterator.
• 64b1a12 Allow identity (primary key auto-increment) types to be overridden.
• 2721a90 Quote the table name correctly in InsertBuilder.
• 1be8a52 Add hashCode() implementation to ProductValue.
• 5be75d3 Add regression test for grouping by 3 columns.
• 05ded5c Add documentation about using connection pools.
• 57d886f Update documentation for new table definitions and tuple syntax.
• b28d2a1 Fix build for building against Scala 2.11
• 74ecd59 Don’t mark types as observed in dumps and when building typed copies.
• 56cdd2d Fix MatchError in tree dumps.
• 3efe3d6 Fix typos
• 81e50a7 Fix code style, transaction example, line wrap, search button layout, typos
• 8829bf9 updates docs to not show dynamicSession as default
• 621947a adjusted docs to match changes regarding dynamicSession in 83d470796c2836d1a66d5b00726bc152bec63ac6
• 98eee6d fixes compilation errors in dockets:test (which somehow creeped in)
• 5bb13eb adjusted docs for OSX
• c3b771a Add Google Analytics token to the generated docs fixes assembla ticket #188
• d755e69 added connection / transaction docs
• a67ca6c changed to docs Slick theme
• e75919e prepare for theme change (code lines < 100 chars)
• fa3c659 Add some scaladoc comments to the lifted embedding.
• 353a260 Update the Typesafe Project & Developer Guidelines.
• 27fc9ca Remove some cruft from the AST.
• 5bc8d29 Implement the new column expansion and flattening scheme.
• 7b114bf Find all referenced table columns in inferTypes.
• 29fc842 Create a TableExpansion when creating a TableNode.
• 697dc78 Simplify tagging and ref encoding.
• e33ba26 Simplify the Shape API + implementation and MapperTest
• e0c8db6 Support for easy type mapping in Shapes.
• 9e566e2 Remove Node.apply and rename NodeGenerator.nodeDelegate to .toNode.
• 379b649 Move the conversion of values to Nodes into Shape.
• 78bad9e Move encodeRef functionality for container types into Shape.
• 5e98612 Simplify the creation of packed Shape of QueryParameters.
• 531607d fixes doctest:test compilation errors introduced by 83d470796c2836d1a66d5b00726bc152bec63ac6
• db9116d Slick 2.0.0-M2 release
• 36f95d7 Use the ++ operator for unionAll.
• 5978155 Allow the use of += and ++= for more complex inserts in JdbcProfile.
• b16cbc5 Improve threadLocalSession API
• 6cd987e Make tuple extension methods optional.
• 820670b Sprinkle some macro sugar on TableQuery.
• 6a3467e Introduce the new table model.
• 5506063 Add query-based DDL and Insert APIs.
• cf1b244 Complete separation of Nodes and Reps.
• 2f6e031 Disentangle lifted embedding tables from TableNodes.
• 73c79b3 Remove WithOp.
• cd1e60c Rebase topic/tuples-everywhere.
• 8239fb7 Simplify typing of Nodes.
• 64e1f6b Some minor cleanup work
• a63846d Remove “by” Symbol from GroupBy.
• 11afbd6 Implement SQL-like count(*) semantics workaround in QueryInterpreter.
• 83c487d Improve handling of types in the AST and query compiler.

--
Stefan Zeiger
Slick Tech Lead
Typesafe - Build Reactive Apps!
Twitter: @StefanZeiger

[Viktor Klang]

Wow, nice list of improvements!

--
 
---
You received this message because you are subscribed to the Google Groups "Slick / ScalaQuery" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalaquery+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Viktor Klang
Director of Engineering - Typesafe

Build Reactive Apps!

[Andrew Gaydenko]

On Friday, November 8, 2013 5:22:20 PM UTC+4, Stefan Zeiger wrote:

....and Slick Testkit Example projects have not been updated yet.

Thanks to the team!

Stefan, will we (the group subscribers) know when testkit will be in par with the code?
I use the testkit as a documentation (and advice all to do it) :)

[Stefan Zeiger]

Testkit is part of the main codebase and used to test Slick itself. It is always up to date and published along with every version. It's only the testkit-example project that hasn't been updated.

[Andrew Gaydenko]

On Friday, November 8, 2013 8:31:59 PM UTC+4, Stefan Zeiger wrote:

Testkit is part of the main codebase and used to test Slick itself. It is always up to date and published along with every version. It's only the testkit-example project that hasn't been updated.

Aha, I see, thanks for the clarification. I had feeling of mistake :) as far as test kit must be in par with a code (as it is in fact), just didn't distinguish testkit and testkit-example.

[ijuma]

Nice set of improvements. :) I was aware of all apart from the soft insert changes. That was a nice surprise. :)

Ismael

[Pedro Furlanetto]

Quite impressive list of improvements!

Congrats Stefan, Christopher and Typesafe!

This one particularly catches my eyes:

- A new model for pre-compiled queries replaces the old QueryTemplate

abstraction. Any query (both, actual collection-valued Query objects
and scalar queries) or function from Column types to such a query can

now be lifted into a Compiledwrapper. Lifted functions can be applied

(without having to recompile the query), and you can use both monadic
composition of Compiled values or just get the underlying query and
use that for further composition.

Can I compose both compiled and non-compiled queries in a single
query? I suppose composing compiled values still carries a cost,
hopefully a lot cheaper than raw Query objects.

[Adam Mackler]

This is most excellent and eagerly-awaited news.  Thank you for your hard work!!

On Friday, November 8, 2013 8:22:20 AM UTC-5, Stefan Zeiger wrote:

We have just released Slick 2.0.0-M3, the third milestone for Slick 2.0. It should show up on Maven Central within the next few hours. You can find the source code here: https://github.com/slick/slick/tree/2.0.0-M3. Please see http://slick.typesafe.com/docs/ for documentation.

-- 

[Stefan Zeiger]

On 2013-11-11 5:12, Pedro Furlanetto wrote:

Quite impressive list of improvements!

Congrats Stefan, Christopher and Typesafe!

This one particularly catches my eyes:

- A new model for pre-compiled queries replaces the old QueryTemplate
abstraction. Any query (both, actual collection-valued Query objects
and scalar queries) or function from Column types to such a query can
now be lifted into a Compiledwrapper. Lifted functions can be applied
(without having to recompile the query), and you can use both monadic
composition of Compiled values or just get the underlying query and
use that for further composition.

Can I compose both compiled and non-compiled queries in a single
query? I suppose composing compiled values still carries a cost,
hopefully a lot cheaper than raw Query objects.

Compiled queries are fully compositional. The Cached type is copointed, so you can always exrtract the underlying query or query function, compose that with something else, and then wrap it in a new Compiled object or execute it directly. The map() and flatMap() methods on Compiled also give you monadic composition which can be easier to use in a for comprehension (think of Option composition; it's the same thing there: You can either get the values out compose directly).

You can also wrap a query function (i.e. a function with Column parameters and a run()nable result) into a CompiledFunction, apply function parameters (which will only compile the query once, the first time an applied version is executed) to get an AppliedCompiledFunction, then extract the applied version as a Query for further use. The only operation that benefits from the caching is function application (like using the old QueryTemplates), everything else has the same performance as regular query composition.

Oh, I forgot to mention a feature in the release notes: This new caching scheme also works for updates and deletes!

[Reid Spencer]

Stefan,

I've been awaiting this release eagerly and quite looking forward to using all its new capabilities. However, after trying for a while, I am unable to overcome some of the basic differences. In particular, what happened to Database and Session?

I look at the top of this page: http://slick.typesafe.com/doc/2.0.0-M3/connection.html where it says:

You can tell Slick how to connect to the database of your choice by creating a Database object,

and I click on the Database link and it takes me to a 404. Indeed, when I load 2.0.0-M3 into IntelliJ there is no Database class, nor Session.  Okay, so maybe this is just old crusty documentation. So then I looked at the GettingStarted page where it says:

  // use the right Slick version here:
  "com.typesafe.slick" %% "slick" % "2.0.0",

Ahah! I was using 2.0.0-M3 so I quickly changed it to 2.0.0 and tried to load my sbt project again. Unfortunately, maven was not able to find that library although it did find 2.0.0-M3. Another documentation error?

At this point, I've gone back to 1.0.1 because I can't figure out how to use it properly and the documentation is not helpful. 

How exactly does one get access to a database in 2.0.0-M3 ?

Help, please?

Thanks,

Reid.

On Friday, November 8, 2013 8:22:20 AM UTC-5, Stefan Zeiger wrote:

[Reid Spencer]

Okay I just discovered "DatabaseComponent" trait which seems to need to be mixed in to EVERY class that uses the database? Is that the intention? That's a bit awkward for me. I have many classes that do things like:

def foo(implicit session: Session) { ... }

So now in every class that I have such a function, I should mix in DatabaseComponent?  If there's a less intrusive way of doing this, I would like to know how.

Thanks,

Reid.

[Christopher Vogt]

Hi Reid,

Slick-2.0.0-M3 is a milestone release, not a stable release. So expect
(and please report :)) some issues, which should be fixed when we
release Slick-2.0.0-RC1.

Stuff moved around in Slick's code internally and the documentation is
lacking behind. The Database class is now
http://slick.typesafe.com/doc/2.0.0-M3/api/#scala.slick.jdbc.JdbcBackend$DatabaseFactoryDef
. But you still the same old Database.forURL or Database.forDataSource.

User code stayed mostly the same except for a few things. The `Tag`
argument to table classes and tuples in projections (like the `*`
projection) come to mind.

Thx
Chris

On 13.11.13 16:26, Reid Spencer wrote:
> Stefan,
>
> I've been awaiting this release eagerly and quite looking forward to
> using all its new capabilities. However, after trying for a while, I am
> unable to overcome some of the basic differences. In particular, what
> happened to Database and Session?
>
> I look at the top of this
> page: http://slick.typesafe.com/doc/2.0.0-M3/connection.html where it says:
>
> You can tell Slick how to connect to the database of your choice by
> creating a Database

> <http://slick.typesafe.com/doc/2.0.0-M3/api/#scala.slick.session.Database> object,

>
>
> and I click on the Database link and it takes me to a 404. Indeed, when
> I load 2.0.0-M3 into IntelliJ there is no Database class, nor Session.
> Okay, so maybe this is just old crusty documentation. So then I looked
> at theGettingStarted page

> <http://slick.typesafe.com/doc/2.0.0-M3/gettingstarted.html> where it says:
>
> // use the right Slick version here:
> "com.typesafe.slick" %% "slick" % "2.0.0",
>
>
> Ahah! I was using 2.0.0-M3 so I quickly changed it to 2.0.0 and tried to
> load my sbt project again. Unfortunately, maven was not able to find
> that library although it did find 2.0.0-M3. Another documentation error?
>
> At this point, I've gone back to 1.0.1 because I can't figure out how to
> use it properly and the documentation is not helpful.
>
> How exactly does one get access to a database in 2.0.0-M3 ?
>
> Help, please?
>
> Thanks,
>
> Reid.
>
>
> On Friday, November 8, 2013 8:22:20 AM UTC-5, Stefan Zeiger wrote:
>
> Hello,
>
> We have just released Slick 2.0.0-M3, the third milestone for Slick
> 2.0. It should show up on Maven Central within the next few hours.
> You can find the source code here:
> https://github.com/slick/slick/tree/2.0.0-M3

> <https://github.com/slick/slick/tree/2.0.0-M3>. Please see
> http://slick.typesafe.com/docs/ <http://slick.typesafe.com/docs/>

> for documentation.
>
> We published M2 in July but it was never officially announced and
> did not come with updated documentation, so these release notes
> include the changes for both, M2 and M3.
>
>
> These are the major new features added since M1:
>

> *

>
> Table definitions in the Lifted Embedding use a new syntax which
> is slightly more verbose but also more robust and logical,
> avoiding several pitfalls from earlier versions.
>

> *

>
> Table definitions (and their |*| projections) are not restricted
> to flat tuples of columns anymore. They can use any type that
> would be valid as the return type of a Query. The old projection
> concatenation methods |~| and |~:| are still supported but not
> imported by default.
>

> *

>
> In addition to Scala tuples, Slick supports its own |HList|
> abstraction for records of arbitrary size. You can also add
> support for your own record types with only a few lines of code.
> All record types can be used everywhere (including table
> definitions and mapped projections) and they can be mixed and
> nested arbitrarily.
>

> *

>
> Some changes to the API to bring it closer to Scala Collections
> syntax.
>

> *

>
> |threadLocalSession| has been renamed to |dynamicSession| and
> the corresponding methods have distinct names (e.g.

> |withDynSession| vs the standard |withSession|). This allows the

> use of the standard methods without extra type annotations.
> Thread-local sessions are not deprecated but we want to push
> explicit session management (with the now simpler syntax) as the
> default.
>

> *

>
> Some important parts of the query compiler have been rewritten.
> Column flattening and the emulation of |Boolean| which is
> required by some databases should now be more robust.
>

> *

>
> Soft inserts are now the default, i.e. |AutoInc| columns are
> automatically skipped when inserting with |+=|, |++=|, |insert|

> and |insertAll|. This means that you no longer need separate

> projections (without the primary key) for inserts. There are
> separate methods |forceInsert| and |forceInsertAll| in
> |JdbcProfile| for the old behavior.
>

> *

>
> A new model for pre-compiled queries replaces the old
> |QueryTemplate| abstraction. Any query (both, actual
> collection-valued |Query| objects and scalar queries) or
> function from |Column| types to such a query can now be lifted
> into a |Compiled| wrapper. Lifted functions can be applied
> (without having to recompile the query), and you can use both
> monadic composition of |Compiled| values or just get the
> underlying query and use that for further composition.
>
> Note that this is not a production-ready or beta release. The Slick
> Extensions package is not available for this milestone release and

> the Slick Examples <https://github.com/slick/slick-examples> and
> Slick Testkit Example
> <https://github.com/slick/slick-testkit-example> projects have not

> been updated yet.
>
> We expect that the next published version of Slick will be 2.0.0-RC1
> which will integrate code-generator-based type providers and add
> more documentation and bug fixes. It will also come with an updated
> Slick Extensions package.
>
>
> Here is a complete list of changes since M1:
>

> * |b70a2c7|
> <https://github.com/slick/slick/commit/b70a2c7289e9aa4f6e12cf7426c5a91d47e1b4bf>
> Update build for 2.0.0-M3
> * |1c488ea|
> <https://github.com/slick/slick/commit/1c488ea1ddabc2a34f6c60ef176332db49975191>

> Deprecate notIn, add filterNot for orthogonality and conformity
> with Scala collections see
> https://github.com/slick/slick/pull/204

> <https://github.com/slick/slick/pull/204>
> * |d1849b8|
> <https://github.com/slick/slick/commit/d1849b82bc41422327db9225e99090dde434556f>

> Add a separate compiler phase for boolean emulation.

> * |32e8cee|
> <https://github.com/slick/slick/commit/32e8cee316900f7458084fdaaf89b8fe360bdef0>

> bumped scala to 2.10.3, sbt to 0.13.0, mima to 0.1.6

> * |24b0ed7|
> <https://github.com/slick/slick/commit/24b0ed78a4e38dae93a648be80497f53cb5b13ab>

> Fix existing doctests, execute all doctests (including required
> fixes)

> * |2a4d156|
> <https://github.com/slick/slick/commit/2a4d156b18aab39141eacddb0d7c6aaef3ae5af5>

> Fix fusion of Take and Drop operators.

> * |3464b5e|
> <https://github.com/slick/slick/commit/3464b5e176bb21792c9912596156d361a2f1e01d>

> Fix compilation error introduced by merging #232 and #243 together.

> * |48f0648|
> <https://github.com/slick/slick/commit/48f06486cfd32c97a671517411aa64976412531d>

> Add test case for multi-level mapping with <>, prompted by issue
> #78.

> * |c2eb8da|
> <https://github.com/slick/slick/commit/c2eb8da964733d1a4ed963490f30c4573ee69f52>

> Add createDDLInvoker (similar to createInsertInvoker).

> * |c897ad9|
> <https://github.com/slick/slick/commit/c897ad931c3db06a3573cd91a57c913593dcc698>

> Add HList and Nat implementations with Shapes for the HList.

> * |d6428b7|
> <https://github.com/slick/slick/commit/d6428b7e7d3f1a61825484bd061369f4207a8377>
> Simplify custom Shape definitions
> * |99f19fc|
> <https://github.com/slick/slick/commit/99f19fcafb7adc7a85f7a802334b35c51aa90e11>

> Use bind variables for types which do not support literals.

> * |68996f0|
> <https://github.com/slick/slick/commit/68996f06fce5f2b4e68fa59b7ece6ab8e81b2343>

> Skip AutoInc columns by default when inserting data.

> * |bda93a7|
> <https://github.com/slick/slick/commit/bda93a7105f044785b0628275770f2b33b27d2d4>
> Introduce �Compiled� computations to replace parameterized queries.
> * |4ee1c5c|
> <https://github.com/slick/slick/commit/4ee1c5ca9bd0fce645188bb098fabf73134750fe>

> Treat Unit as an empty product type.

> * |bbf9694|
> <https://github.com/slick/slick/commit/bbf9694a1f4cd3e7f792770be808add9ba5679a7>

> Add a common abstraction for literal and parameter columns.

> * |b8eaa59|
> <https://github.com/slick/slick/commit/b8eaa59af22e7e8667da91f03e352b0fce85e5c6>

> Improve Shape encoding to support Columns-level Shapes.

> * |942d98f|
> <https://github.com/slick/slick/commit/942d98fc304a1349162b4040e4c16484291f50da>

> Add a nested Shape for Queries.

> * |f16915d|
> <https://github.com/slick/slick/commit/f16915d8e61e2cd48cdf85649cbbd04ce0fd3e2d>

> Allow unit tests which assure that some code does not type-check.

> * |ff992bb|
> <https://github.com/slick/slick/commit/ff992bb492129674ba730e5e5503eae43d66afd0>

> Add Shape levels to differentiate between flat and nested Shapes.

> * |e9d6f69|
> <https://github.com/slick/slick/commit/e9d6f6927d1d84493849b96d3759f4ad6d4c5b32>

> Running a query to match a specific UUID in MySQL fails in
> 1.0.1. For example, the following code will fail with error

> �UUID does not support a literal representation�.
> * |1c1bf30|
> <https://github.com/slick/slick/commit/1c1bf30b5265cc33cfb85156d34d55f53457dd9b>

> Fuse simple mappings before resolving GroupBy.

> * |009dc35|
> <https://github.com/slick/slick/commit/009dc3506f912533338f02366fcfaadacf4a3fed>

> Flatten nested ProductNodes in GroupBy keys.

> * |01410cd|
> <https://github.com/slick/slick/commit/01410cdbd28c43b88e64759d83c173bb6798784e>
> Use fixed version numbers for fmpp�s dependencies.
> * |d054bf5|
> <https://github.com/slick/slick/commit/d054bf53642e1a6bee2ce3eff84437dc90b0fdd8>
> Rename .elements to .iterator.
> * |64b1a12|
> <https://github.com/slick/slick/commit/64b1a12864bd690656e96a323a329835c7642bcf>

> Allow identity (primary key auto-increment) types to be overridden.

> * |2721a90|
> <https://github.com/slick/slick/commit/2721a901b8fcd266c626a3de1bc0d1ba311bb0da>

> Quote the table name correctly in InsertBuilder.

> * |1be8a52|
> <https://github.com/slick/slick/commit/1be8a52ec7ebf9142b21bf556f1bb737fc6a57e1>

> Add hashCode() implementation to ProductValue.

> * |5be75d3|
> <https://github.com/slick/slick/commit/5be75d3e8440b2c64b6cfeb2a0e6612d785ad835>

> Add regression test for grouping by 3 columns.

> * |05ded5c|
> <https://github.com/slick/slick/commit/05ded5c2269c503c2526a78ced5fa21c89078afd>

> Add documentation about using connection pools.

> * |57d886f|
> <https://github.com/slick/slick/commit/57d886f82a724ba3322664d8e9744610188bd3d1>

> Update documentation for new table definitions and tuple syntax.

> * |b28d2a1|
> <https://github.com/slick/slick/commit/b28d2a1aeefc05efa15971e5f5b23b3eef3b8fc2>

> Fix build for building against Scala 2.11

> * |74ecd59|
> <https://github.com/slick/slick/commit/74ecd593ad2c4f473d238e952a9e7c59c787a093>
> Don�t mark types as observed in dumps and when building typed
> copies.
> * |56cdd2d|
> <https://github.com/slick/slick/commit/56cdd2da7df9b6fd6fbeb17a3d193f5278154f89>

> Fix MatchError in tree dumps.

> * |3efe3d6|
> <https://github.com/slick/slick/commit/3efe3d64f1fd3481f2f94c8b1a6a2eedd5074b18>
> Fix typos
> * |81e50a7|
> <https://github.com/slick/slick/commit/81e50a7baac55373e882dee0b70a854787c5a3f4>

> Fix code style, transaction example, line wrap, search button
> layout, typos

> * |8829bf9|
> <https://github.com/slick/slick/commit/8829bf97f3c48e069b6f7f4d6a12be9d2181aade>

> updates docs to not show dynamicSession as default

> * |621947a|
> <https://github.com/slick/slick/commit/621947a79653c42f1d024460dc7a7f325c401870>

> adjusted docs to match changes regarding dynamicSession in
> 83d470796c2836d1a66d5b00726bc152bec63ac6

> * |98eee6d|
> <https://github.com/slick/slick/commit/98eee6d462cf2ac30fcd07728702ed88b0ad6487>

> fixes compilation errors in dockets:test (which somehow creeped in)

> * |5bb13eb|
> <https://github.com/slick/slick/commit/5bb13eb9ca7626051f00a00548879eb3234f09e6>
> adjusted docs for OSX
> * |c3b771a|
> <https://github.com/slick/slick/commit/c3b771a49071d76a0ff569e823b49014dd88ff39>

> Add Google Analytics token to the generated docs fixes assembla
> ticket #188

> * |d755e69|
> <https://github.com/slick/slick/commit/d755e69e728baeaffa5a23f09f608a6ebd43c5da>

> added connection / transaction docs

> * |a67ca6c|
> <https://github.com/slick/slick/commit/a67ca6c06555d73877cc3a1f052f2a7b53ddc44c>

> changed to docs Slick theme

> * |e75919e|
> <https://github.com/slick/slick/commit/e75919e4d04ba2838631bddda8fcb9cea8d9dbc7>

> prepare for theme change (code lines < 100 chars)

> * |fa3c659|
> <https://github.com/slick/slick/commit/fa3c659b7c502d72298a14478209f397b5b724f3>

> Add some scaladoc comments to the lifted embedding.

> * |353a260|
> <https://github.com/slick/slick/commit/353a260960b0d103ef650d3b70f2ddcf1d987465>

> Update the Typesafe Project & Developer Guidelines.

> * |27fc9ca|
> <https://github.com/slick/slick/commit/27fc9ca19df0df96cc3da4945733aa464a46cfa7>

> Remove some cruft from the AST.

> * |5bc8d29|
> <https://github.com/slick/slick/commit/5bc8d292a0d220cd703c10f79c8d5e655f55ac8d>

> Implement the new column expansion and flattening scheme.

> * |7b114bf|
> <https://github.com/slick/slick/commit/7b114bfd550b49a3dabfbd0173ee3ccc41e4a3b7>

> Find all referenced table columns in inferTypes.

> * |29fc842|
> <https://github.com/slick/slick/commit/29fc8422aeb89ca0132f70ace0045b593a13914d>

> Create a TableExpansion when creating a TableNode.

> * |697dc78|
> <https://github.com/slick/slick/commit/697dc78258a35e86d290b85d0aab752f84f54273>

> Simplify tagging and ref encoding.

> * |e33ba26|
> <https://github.com/slick/slick/commit/e33ba260862cdceef17371c78b9714c22ca22abc>

> Simplify the Shape API + implementation and MapperTest

> * |e0c8db6|
> <https://github.com/slick/slick/commit/e0c8db6cd4d6f429af9678553a03d07999a716d1>

> Support for easy type mapping in Shapes.

> * |9e566e2|
> <https://github.com/slick/slick/commit/9e566e2f7c8375dabc9c36f3b521344685caaa5a>

> Remove Node.apply and rename NodeGenerator.nodeDelegate to .toNode.

> * |379b649|
> <https://github.com/slick/slick/commit/379b649093a98be809bb54cbbcc376aab3058132>

> Move the conversion of values to Nodes into Shape.

> * |78bad9e|
> <https://github.com/slick/slick/commit/78bad9e7e2afad365593d49566b896ed100455c1>

> Move encodeRef functionality for container types into Shape.

> * |5e98612|
> <https://github.com/slick/slick/commit/5e986125db4343f80aff378230dffce850efd7a6>

> Simplify the creation of packed Shape of QueryParameters.

> * |531607d|
> <https://github.com/slick/slick/commit/531607dd785e2cf0ce609d01c064fdf2b182fcaf>

> fixes doctest:test compilation errors introduced by
> 83d470796c2836d1a66d5b00726bc152bec63ac6

> * |db9116d|
> <https://github.com/slick/slick/commit/db9116d41a365987e1231da987a5dff84bc80cdd>
> Slick 2.0.0-M2 release
> * |36f95d7|
> <https://github.com/slick/slick/commit/36f95d7bc83bbbd18f589a9d5e463519b69198e4>

> Use the ++ operator for unionAll.

> * |5978155|
> <https://github.com/slick/slick/commit/59781555b3c360b3805c8afbffb134b030d90d18>

> Allow the use of += and ++= for more complex inserts in JdbcProfile.

> * |b16cbc5|
> <https://github.com/slick/slick/commit/b16cbc5df3ed4085761ae823f2c7c522dcb2e94b>
> Improve threadLocalSession API
> * |6cd987e|
> <https://github.com/slick/slick/commit/6cd987ee1c1d20571407904098fc726700785116>

> Make tuple extension methods optional.

> * |820670b|
> <https://github.com/slick/slick/commit/820670bbea6bbaf5dda8455a3187ba6618b11b76>

> Sprinkle some macro sugar on TableQuery.

> * |6a3467e|
> <https://github.com/slick/slick/commit/6a3467ed349f8b1d67160b4fb090ecdf508b55c2>

> Introduce the new table model.

> * |5506063|
> <https://github.com/slick/slick/commit/550606313bb111bdfc4393ef5ee8567d5a4ccc28>

> Add query-based DDL and Insert APIs.

> * |cf1b244|
> <https://github.com/slick/slick/commit/cf1b244f610143a6604b0f97c3e44138fb950224>

> Complete separation of Nodes and Reps.

> * |2f6e031|
> <https://github.com/slick/slick/commit/2f6e031f845cf917f734a28440ff240978b242ff>

> Disentangle lifted embedding tables from TableNodes.

> * |73c79b3|
> <https://github.com/slick/slick/commit/73c79b3506bdd9d84545ba9bee22e4c0acc35816>
> Remove WithOp.
> * |cd1e60c|
> <https://github.com/slick/slick/commit/cd1e60c7d18157ffc8e19b2ef6d93e36f512e1be>
> Rebase topic/tuples-everywhere.
> * |8239fb7|
> <https://github.com/slick/slick/commit/8239fb731922a946b1210f84b00f5487377c747e>
> Simplify typing of Nodes.
> * |64e1f6b|
> <https://github.com/slick/slick/commit/64e1f6b0460d79cd0a37767a0c27c93561ce8019>
> Some minor cleanup work
> * |a63846d|
> <https://github.com/slick/slick/commit/a63846d4eaee0c1b00fb85220ce82763f82d7b72>
> Remove �by� Symbol from GroupBy.
> * |11afbd6|
> <https://github.com/slick/slick/commit/11afbd637351bea16bfdbdcf242d1c0ce582c97f>

> Implement SQL-like count(*) semantics workaround in
> QueryInterpreter.

> * |83c487d|
> <https://github.com/slick/slick/commit/83c487ded5e79804a4f4e45e9214e6e4e04bac8d>

> Improve handling of types in the AST and query compiler.
>
> --
> Stefan Zeiger

> /Slick <http://slick.typesafe.com> Tech Lead/
> Typesafe <http://typesafe.com> - Build Reactive Apps!
> Twitter: @StefanZeiger <http://twitter.com/#%21/StefanZeiger>

[Christopher Vogt]

Hi Reid,

Session became a member of the Slick cake, e.g. H2Driver.Backend#Session.

> So now in every class that I have such a function, I should mix in
> DatabaseComponent? If there's a less intrusive way of doing this, I
> would like to know how.

You should be fine with something like this on top of your code:
type Session = H2Driver.Backend#Session

Chris

[Reid Spencer]

Hi Chris,

Comments below ..

On Nov 13, 2013, at 11:28 AM, Christopher Vogt <jan.christ...@gmail.com> wrote:

Hi Reid,

Slick-2.0.0-M3 is a milestone release, not a stable release. So expect
(and please report :)) some issues, which should be fixed when we
release Slick-2.0.0-RC1.

Yes, I understand about milestone releases. :) I’m not expecting perfection, just trying to assess the impact to my code base. 

Stuff moved around in Slick's code internally and the documentation is
lacking behind. The Database class is now
http://slick.typesafe.com/doc/2.0.0-M3/api/#scala.slick.jdbc.JdbcBackend$DatabaseFactoryDef
. But you still the same old Database.forURL or Database.forDataSource.

I note that there are four DatabaseFactoryDef definitions in a variety of places:

scala.slick.backend.DatabaseComponent

scala.slick.jdbc.JdbcBackend

scala.slick.memory.DistributedBackend

scala.slick.memory.HeapBackend

It is very important for my use case that my use of Slick can work with any database backend, JDBC or not. So, I’m suspecting that in the generic (abstract) case, I want to use scala.slick.backend.DatbaseComponent and the traits it defines and only use one of the others in a concrete context. Am I understanding the design correctly here?

User code stayed mostly the same except for a few things. The `Tag`
argument to table classes and tuples in projections (like the `*`
projection) come to mind.

Not for my code base. :) The changes in 2.0.0. cause HUNDREDS of compile errors because of the changes to Session.

One of the things I do with Slick is to create reusable table traits that can be mixed in to concrete table definitions. For example:

 trait CreatableTable[S <: Creatable] extends Table[S] {

    def created = column[DateTime](nm("created"), O.Nullable) // FIXME: Dynamic Date required!

    lazy val findSinceQuery = for {

      created <- Parameters[DateTime] ;

      e <- this if (e.created > created)

    } yield e

    case class CreatedSince(d: DateTime) extends FinderOf[S] { override def apply() = findSinceQuery(d).list }

  }

That way, the handling of columns and their supporting queries and updates is regular across all the tables. I utilize the “FinderOf” trait to implement a generic find mechanism where a case class’s apply method invokes the query.  That way, significant details such as complex argument computations can be cached too.  

This might not be possible with 2.0 since the table itself is no longer queryable. I will obviously have to refactor, but to suggest that the “small” differences in Slick’s 2.0 API will yield “user code stayed mostly the same” is a bit misleading :)

       Introduce “Compiled” computations to replace parameterized queries.

     * |4ee1c5c|
       <https://github.com/slick/slick/commit/4ee1c5ca9bd0fce645188bb098fabf73134750fe>
       Treat Unit as an empty product type.
     * |bbf9694|
       <https://github.com/slick/slick/commit/bbf9694a1f4cd3e7f792770be808add9ba5679a7>
       Add a common abstraction for literal and parameter columns.
     * |b8eaa59|
       <https://github.com/slick/slick/commit/b8eaa59af22e7e8667da91f03e352b0fce85e5c6>
       Improve Shape encoding to support Columns-level Shapes.
     * |942d98f|
       <https://github.com/slick/slick/commit/942d98fc304a1349162b4040e4c16484291f50da>
       Add a nested Shape for Queries.
     * |f16915d|
       <https://github.com/slick/slick/commit/f16915d8e61e2cd48cdf85649cbbd04ce0fd3e2d>
       Allow unit tests which assure that some code does not type-check.
     * |ff992bb|
       <https://github.com/slick/slick/commit/ff992bb492129674ba730e5e5503eae43d66afd0>
       Add Shape levels to differentiate between flat and nested Shapes.
     * |e9d6f69|
       <https://github.com/slick/slick/commit/e9d6f6927d1d84493849b96d3759f4ad6d4c5b32>
       Running a query to match a specific UUID in MySQL fails in
       1.0.1. For example, the following code will fail with error

       “UUID does not support a literal representation”.

     * |1c1bf30|
       <https://github.com/slick/slick/commit/1c1bf30b5265cc33cfb85156d34d55f53457dd9b>
       Fuse simple mappings before resolving GroupBy.
     * |009dc35|
       <https://github.com/slick/slick/commit/009dc3506f912533338f02366fcfaadacf4a3fed>
       Flatten nested ProductNodes in GroupBy keys.
     * |01410cd|
       <https://github.com/slick/slick/commit/01410cdbd28c43b88e64759d83c173bb6798784e>

       Use fixed version numbers for fmpp’s dependencies.

       Don’t mark types as observed in dumps and when building typed

       Remove “by” Symbol from GroupBy.

     * |11afbd6|
       <https://github.com/slick/slick/commit/11afbd637351bea16bfdbdcf242d1c0ce582c97f>
       Implement SQL-like count(*) semantics workaround in
       QueryInterpreter.
     * |83c487d|
       <https://github.com/slick/slick/commit/83c487ded5e79804a4f4e45e9214e6e4e04bac8d>
       Improve handling of types in the AST and query compiler.

   --
   Stefan Zeiger
   /Slick <http://slick.typesafe.com> Tech Lead/
   Typesafe <http://typesafe.com> - Build Reactive Apps!
   Twitter: @StefanZeiger <http://twitter.com/#%21/StefanZeiger>

--

---
You received this message because you are subscribed to the Google
Groups "Slick / ScalaQuery" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to scalaquery+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

---
You received this message because you are subscribed to a topic in the Google Groups "Slick / ScalaQuery" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scalaquery/xNtPT6sexXI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scalaquery+...@googlegroups.com.

[Reid Spencer]

Chris,

None of my code wants to assume a particular driver. I fully intend, at some point, to write a completely asynch driver that is not JDBC based.  Because of slick’s type safety, I have some guarantees that my existing code will work as well as that driver’s implementation eventually will. So, to suggest that I map Session to a PARTICULAR driver’s implementation really does not sit well with me. It needs to work with ANY database driver. My clients can pick from among any supported by slick (and eventually by my own drivers).

If I’m working generically (abstractly), isn’t the correct definition more like:

type Session = scala.slick.backend.DatabaseComponent.SessionDef

?

Or am I missing something here?

Reid

[Christopher Vogt]

> type Session = scala.slick.backend.DatabaseComponent.SessionDef

Use this instead, it should be more stable:

type Session = scala.slick.profile.BasicProfile#Backend#Session

Chris

[Reid Spencer]

Thank you ! :)

[Christopher Vogt]

Hi Reid,

> It is very important for my use case that my use of Slick can work with
> any database backend, JDBC or not.

be aware that we do not guarantee exactly identical runtime semantics at
this point. The behavioral differences between difference DBMS are too
subtle in some things. If you want to be sure, run tests. Slick test-kit
allows to write tests against all supported drivers. Besides our own
code and docs, you can find an example of this here:
https://github.com/nafg/slick-migration-api

> So, I�m suspecting that in the

> generic (abstract) case, I want to use
> scala.slick.backend.DatbaseComponent and the traits it defines and only
> use one of the others in a concrete context. Am I understanding the
> design correctly here?

Use JdbcProfile#Backend instead (we only have jdbc backends right now
and type mappers only with with this one at the moment).

> Not for my code base. :) The changes in 2.0.0. cause HUNDREDS of compile
> errors because of the changes to Session.

If you exclude duplicates and follow up errors, it should be just a few.

> One of the things I do with Slick is to create reusable table traits
> that can be mixed in to concrete table definitions. For example:

> [...]

> That way, the handling of columns and their supporting queries and
> updates is regular across all the tables.

That's encouraged.

> trait CreatableTable[S <: Creatable] extends Table[S] {
>
> def created = column[DateTime](nm("created"), O.Nullable) // FIXME:
> Dynamic Date required!
>
> lazy val findSinceQuery = for {
> created <- Parameters[DateTime] ;
> e <- this if (e.created > created)
> } yield e
>
> case class CreatedSince(d: DateTime) extends FinderOf[S] { override
> def apply() = findSinceQuery(d).list }
> }
>

> I utilize the �FinderOf� trait
> to implement a generic find mechanism where a case class�s apply method
> invokes the query.
> [...]

> This might not be possible with 2.0 since the table itself is no longer
> queryable.

The changes in table definitions probably cause the largest change to
user code, but only at the place, where you define tables, which should
be rather localized (as opposed to your queries).

Instead of what you do right now, you could do the following. (Be aware
of https://issues.scala-lang.org/browse/SI-7970 in case you run into it
during refactoring).

type Session = scala.slick.driver.JdbcProfile#Backend#Session

// Re-useable "creatable" logic
trait CreatableTable[T <: Creatable] extends Table[T]{
def created = column[DateTime]("LABELONE")
}
trait CreatableTableHelpers[TT <: CreatableTable[T],T <: Creatable]{
val table : TableQuery[TT,T]
lazy val findSinceQuery = Compiled{
d:Column[DateTime] => table.filter(_.created > d)
}
case class CreatedSince(d: String) {
def apply()(implicit session:Session) : Seq[T] =
findSinceQuery(d).run(session)
}
}

// a sample table description
type MyTableElementType = (Long,DateTime)
class MyTable(tag: Tag) extends Table[MyTableElementType]
(tag, "things") with Foo[MyTableElementType]{
def id = column[Long]("id", O.PrimaryKey, O.AutoInc)
def * = (id, created)
}
val MyTable = TableQuery[MyTable]

// a corresponding DAO object
object MyTableHelpers extends FooHelpers[MyTable,MyTableElementType]{
val table = MyTable
}

// enable DAO methods directly on the TableQuery object
implicit def MyTableExtensions( t:MyTable.type ) = MyTableHelpers

Your query code should stay the same this way. The re-usable
pre-compiled query traits required some hoops, but make sense indeed :).
If you are annoyed by having to pass too many type arguments to traits
like FooHelpers in the above code, you can consider making them type
members and having a common helper super trait.

> I will obviously have to refactor, but to suggest that the

> �small� differences in Slick�s 2.0 API will yield �user code stayed
> mostly the same� is a bit misleading :)

Less misleading: The query code stays mostly the same, the table
description code has to be adapted more. Especially the fact that you
had finders in the old table objects added some complication. My
suggesting is to put them in a separate object, e.g. MyTableDao.findSince .

Thank you for going through the pain of early migration. This will help
us significantly in writing a better migration guide!

Best regards

Chris

[Stefan Zeiger]

On 2013-11-08 14:22, Stefan Zeiger wrote:

Note that this is not a production-ready or beta release. The Slick Extensions package is not available for this milestone release and the Slick Examples and Slick Testkit Example projects have not been updated yet.

Updating Slick Extensions for 2.0 was less work than I expected. I just published a release for 2.0.0-M3. See http://slick.typesafe.com/doc/2.0.0-M3/extensions.html on how to add it to your project.

[Stefan Zeiger]

On 2013-11-13 17:51, Reid Spencer wrote:

Chris,

None of my code wants to assume a particular driver. I fully intend, at some point, to write a completely asynch driver that is not JDBC based. �Because of slick�s type safety, I have some guarantees that my existing code will work as well as that driver�s implementation eventually will. So, to suggest that I map Session to a PARTICULAR driver�s implementation really does not sit well with me. It needs to work with ANY database driver. My clients can pick from among any supported by slick (and eventually by my own drivers).

If I�m working generically (abstractly), isn�t the correct definition more like:

type Session = scala.slick.backend.DatabaseComponent.SessionDef

The Backend hierarchy is independent of the Driver hierarchy, in particular there are no path-dependent types to the Backend that would ensure that it comes from the right Driver. This gives you an adequate level of type-safety while being much less of a hassle to use in practice. The Drivers are tied to a specific Backend at the leafs of the Profile hierarchy, i.e. JdbcProfile mandates a JdbcBackend (and this cannot be overridden in subclasses of JdbcProfile).

You should be able to work with Database and Session as before except you now have a choice between different Backends. Just import them from scala.slick.jdbc.JdbcBackend instead of scala.session and you should be fine.

[Stefan Zeiger]

On 2013-11-13 17:45, Reid Spencer wrote:

I note that there are four DatabaseFactoryDef definitions in a variety of places:

scala.slick.backend.DatabaseComponent

scala.slick.jdbc.JdbcBackend

scala.slick.memory.DistributedBackend

scala.slick.memory.HeapBackend

It is very important for my use case that my use of Slick can work with any database backend, JDBC or not. So, I�m suspecting that in the generic (abstract) case, I want to use scala.slick.backend.DatbaseComponent and the traits it defines and only use one of the others in a concrete context. Am I understanding the design correctly here?

Usually you should abstract over the Driver/Profile at the desired level (at the moment RelationalProfile and JdbcProfile make sense) and import simple._ from the driver. This will give you the right Backend level for the Profile level.

Not for my code base. :) The changes in 2.0.0. cause HUNDREDS of compile errors because of the changes to Session.

That is an unfortunate consequence of making the code more modular in 2.0. Once you adapt your design to get everything through the driver, it should be more resilient to such changes in the future.

This might not be possible with 2.0 since the table itself is no longer queryable. I will obviously have to refactor, but to suggest that the �small� differences in Slick�s 2.0 API will yield �user code stayed mostly the same� is a bit misleading :)

The differences are small for common use cases with a low level of internal abstraction (e.g. abstract over database drivers, define a schema and queries against that schema). If you have code that abstracts over queries or tables, it can be considerably more difficult to update that to the new model.

--
Stefan Zeiger
Slick Tech Lead

Typesafe - Build Reactive Apps!
Twitter: @StefanZeiger

[Marceli Narcyz]

I'm currently unable to get the "soft insert" feature working in a test app. I'm obviously using the new 2.0.0-M3 version.

The 2.0.0-M3 documentation isn't updated regarding to this feature. I don't see any sample code that uses this.

Is this feature really in M3? Can I see a simple code snippet?

[Stefan Zeiger]

On 2013-11-22 15:51, Marceli Narcyz wrote:

I'm currently unable to get the "soft insert" feature working in a test app. I'm obviously using the new 2.0.0-M3 version.

The 2.0.0-M3 documentation isn't updated regarding to this feature. I don't see any sample code that uses this.

Is this feature really in M3? Can I see a simple code snippet?

There's not much to see because this works automatically. Here's a test case: https://github.com/slick/slick/blob/master/slick-testkit/src/main/scala/com/typesafe/slick/testkit/tests/InsertTest.scala#L95-97. You can see the forced insert in action just below those lines.

[Stefan Zeiger]

On 2013-11-14 14:57, Stefan Zeiger wrote:

On 2013-11-08 14:22, Stefan Zeiger wrote:

Note that this is not a production-ready or beta release. The Slick Extensions package is not available for this milestone release and the Slick Examples and Slick Testkit Example projects have not been updated yet.

Updating Slick Extensions for 2.0 was less work than I expected. I just published a release for 2.0.0-M3. See http://slick.typesafe.com/doc/2.0.0-M3/extensions.html on how to add it to your project.

slick-examples and slick-testkit-example have also been updated for 2.0.0-M3 and tagged in github, so the links from the 2.0.0-M3 manual to the examples will work.

[Sven Pedersen]

I'm currently writing Slick code to target an old schema with two tables > 22 columns. How do I use the HList code? I've got 2.0-M3 working fine in other respects under Scala 2.10.3.
Here's the syntax I'm currently using with tuples. What would I do to use HLists? I don't see any in the examples and only a brief mention in the newly updated docs.

case class Joiner(
      id: Int,
      name: Option[String],
      contact: Option[String]
  )
 
  class Joiners(tag: Tag) extends Table[Artist](tag, "joiner") {
    def id = column[Int]("id", O.PrimaryKey, O.AutoInc, O.DBType("int(11)"))
    def name = column[String]("name", O.DBType("varchar(255)"), O.Nullable)
    def contact = column[String]("contact", O.DBType("text"), O.Nullable)
    def * = (id, name.?, contact.?) <> (Joiner.tupled, Joiner.unapply)
  }
  val joiners = TableQuery[Joiners]

On Friday, November 8, 2013 8:22:20 AM UTC-5, Stefan Zeiger wrote:

[Christopher Vogt]

Sven. In the future please cross-link topics when you post them also on
stack overflow!

http://stackoverflow.com/questions/20555304/how-can-i-use-the-new-slick-2-0-hlist-to-overcome-22-column-limit/20555847?noredirect=1#comment30763610_20555847

[Sven Pedersen]

OK, I worked my way through an example table with 33 columns using HList as described

package code.model

import java.sql.Date
import scala.slick.driver.H2Driver.simple._
import scala.slick.collection.heterogenous._
import syntax._

class Joiners(tag: Tag) extends Table[Int :: Option[String] :: Option[String] ... :: HNil](tag, "joiner") {
  def id = column[Int]("id", ...
  def name = column[String("name", ...
  def contact = column[String("contact", ...  
  ...
  def col33 = column[String]("column33", ...
  def * = id :: name :: contact ... :: HNil
}

And when I compile the source, it causes a heap overflow. In Eclipse/Scala-IDE (3.0.2) I get "Error during askOption". Using SBT to build directly I left it compiling all night long and found it still going in the morning. Before switching to HList and adding another ~15 columns it took 5 seconds to build on my Macbook Air (Core i7 w/8GB ram). What should I do to help track down the problem?
Thanks,
Sven

[Christopher Vogt]

> What should I do to help track down the problem?

Sending some code that allows us to easily reproduce the problem would
be of great help. Thank you :)!

Chris

[Sven Pedersen]

OK, I updated some libraries (and the compiler) and got a more meaninful error instead of a crash (see attached source):

BreakSlickHList.scala:39: class ThirtyTwoCols needs to be abstract, since method * in class AbstractTable of type => scala.slick.lifted.ProvenShape[scala.slick.collection.heterogenous.syntax.::[Int,scala.slick.collection.heterogenous.syntax.::[Option[Int],scala.slick.collection.heterogenous.syntax.::[Option[String],scala.slick.collection.heterogenous.syntax.::[String,scala.slick.collection.heterogenous.syntax.::[Option[java.sql.Date],scala.slick.collection.heterogenous.syntax.::[Option[Int],scala.slick.collection.heterogenous.syntax.::[Int,scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Option[Double],scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Option[BigDecimal],scala.slick.collection.heterogenous.syntax.::[Option[Double],scala.slick.collection.heterogenous.syntax.::[Option[Double],scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Option[Double],scala.slick.collection.heterogenous.syntax.::[Option[Double],scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Option[Double],scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Option[Int],scala.slick.collection.heterogenous.syntax.::[Option[Double],scala.slick.collection.heterogenous.syntax.::[Float,scala.slick.collection.heterogenous.syntax.::[Float,scala.slick.collection.heterogenous.syntax.::[Float,scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Option[Short],scala.slick.collection.heterogenous.syntax.::[Option[String],scala.slick.collection.heterogenous.syntax.::[Option[String],scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Option[Double],scala.slick.collection.heterogenous.syntax.HNil]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] is not defined
[error]   class ThirtyTwoCols(tag: Tag) extends Table[


Thanks!
--Sven

[Christopher Vogt]

> OK, I updated some libraries (and the compiler) and got a more meaninful
> error instead of a crash (see attached source):

Which library, which compiler?

> BreakSlickHList.scala:39: class ThirtyTwoCols needs to be abstract,
> since method * in class AbstractTable of type =>
> scala.slick.lifted.ProvenShape[scala.slick.collection.heterogenous.syntax.::[Int,scala.slick.collection.heterogenous.syntax.::[Option[Int],scala.slick.collection.heterogenous.syntax.::[Option[String],scala.slick.collection.heterogenous.syntax.::[String,scala.slick.collection.heterogenous.syntax.::[Option[java.sql.Date],scala.slick.collection.heterogenous.syntax.::[Option[Int],scala.slick.collection.heterogenous.syntax.::[Int,scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Option[Double],scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Option[BigDecimal],scala.slick.collection.heterogenous.syntax.::[Option[Double],scala.slick.collection.heterogenous.syntax.::[Option[Double],scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Option[Double],scala.slick.collection.heterogenous.syntax.
::[Option[Double],scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Option[Double],scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Option[Int],scala.slick.collection.heterogenous.syntax.::[Option[Double],scala.slick.collection.heterogenous.syntax.::[Float,scala.slick.collection.heterogenous.syntax.::[Float,scala.slick.collection.heterogenous.syntax.::[Float,scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Option[Short],scala.slick.collection.heterogenous.syntax.::[Option[String],scala.slick.collection.heterogenous.syntax.::[Option[String],scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Boolean,scala.slick.collection.heterogenous.syntax.::[Option[Double],scala.slick.collection.heterogenous.syntax.HNil]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
]]]
> is not defined
> [error] class ThirtyTwoCols(tag: Tag) extends Table[

You are missing the def * method in ThirtyTwoCols, just as it says.
Probably a mistake while refactoring.

Chris

[Sven Pedersen]

OK, sorry, that was wrong. I upgraded from Scala 2.10.0 to Scala 2.10.3 (I think the Eclipse version was already updated). I removed all libraries except Slick. The version I just sent was missing the * projection, thus the error. Now I'm sending the version that does not compile at all and brings Eclipse to its knees.
--Sven

[Marc Siegel]

Wow! Congratulations.

[Sven Pedersen]

I cut down my code to be more minimal, and here's the error I got (from SBT):
bad symbolic reference. A signature in HList.class refers to type Aliases
 in package scala.reflect.macros which is not available.
 It may be completely missing from the current classpath, or the version on
 the classpath might be incompatible with the version used when compiling HList.class.
 one error found
(compile:compile) Compilation failed

Here's my current code, and attached you'll find the SBT build file.

package code.model
import java.sql.Date
import scala.slick.driver.H2Driver.simple._
import scala.slick.collection.heterogenous._
import syntax._

class DatabaseSchema {
  class BreakHList(tag: Tag) extends Table[Int :: Option[Int] :: Option[String] :: String :: Option[Date] :: HNil](tag, "test_hlist") {
    def col1 = column[Int]("col1", O.PrimaryKey, O.AutoInc, O.DBType("int(11)"))
    def col2 = column[Option[Int]]("col2", O.DBType("int(11)"))
    def col3 = column[Option[String]]("col3", O.DBType("VARCHAR(255)"))
    def col4 = column[String]("col4", O.DBType("VARCHAR(255)"), O.Default(""))
    def col5 = column[Option[Date]]("col5", O.DBType("date"))
    def * = col1 :: col2 :: col3 :: col4 :: col5 :: HNil
  }
  val test_hlist = TableQuery[BreakHList]

[Christopher Vogt]

> bad symbolic reference. A signature in HList.class refers to type Aliases
> in package scala.reflect.macros which is not available.

That's a bug in Slick I just discovered as well. We have an unwanted
dependency on the scala.reflect package. When you add
"org.scala-lang" % "scala-reflect" % "2.10.3"
to your dependencies it goes away.

You original problem is more tricky however. The new Slick HLists seem
to trigger implicit search times exponential in the length of the HList,
which may not be trivial to fix. We also had another compiler related
issue with HLists a few days back. We'll have to see if that's something
we can still fix for 2.0 or if it has to wait for 2.1.
https://github.com/slick/slick/issues/577

The old workaround to work with tables >22 columns are nested tuples as
shown here:
https://github.com/slick/slick/blob/master/slick-testkit/src/main/scala/com/typesafe/slick/testkit/tests/JdbcMapperTest.scala#L102

Chris

[Christopher Vogt]

On 17.12.13 21:39, Christopher Vogt wrote:
>> bad symbolic reference. A signature in HList.class refers to type Aliases
>> in package scala.reflect.macros which is not available.
>
> That's a bug in Slick I just discovered as well. We have an unwanted
> dependency on the scala.reflect package. When you add
> "org.scala-lang" % "scala-reflect" % "2.10.3"
> to your dependencies it goes away.

Fixed in master