loinburger posted:

I used Slick up until about six months ago - it may have gotten better since then, but at the time vanilla Slick was reliant on case classes and tuples and all of their attendant restrictions. However, it's got a code generation tool that lets you bypass those restrictions (generating classes instead of case classes to represent rows), and that also saved us a boatload of time in refactoring (this was a startup and so the database kept changing on us) because the code generation tool would read the metadata from the database tables and produce appropriately typed row classes.

Almost all of the database writes were from JSON in POST/PUT requests, and so the code generation tool let us generate code to:
1. Validate the JSON (ensure that each key corresponded to a valid column name)
2. Loop through the JSON, convert its untyped values to the appropriate type (or throw an exception), and update the appropriate row objects
3. Update the appropriate join tables to keep the database consistent (this was done with a hand-coded Map, we were planning on automatically generating this Map using foreign key constraints but then the company more or less went bankrupt)

I can give you some example code if you want. The learning curve was a bit steep, but in the end something like 25% of our back-end code was being generated by Slick.