Slick is Typesafe‘s modern database query and access library for Scala. It allows you
to work with stored data almost as if you were using Scala collections while
at the same time giving you full control over when a database access happens
and which data is transferred. You can also use SQL directly.

vallimit=10.0// Your query could look like this:(for(c<-coffees;ifc.price<limit)yieldc.name).list// Or using more plain SQL String Interpolation:sql"select COF_NAME from COFFEES where PRICE < $limit".as[String].list// Both queries result in SQL equivalent to:// select COF_NAME from COFFEES where PRICE < 10.0

When using Scala instead of raw SQL for your queries you benefit from compile-time safety
and compositionality. Slick can generate queries for different back-end databases including
your own, using its extensible query compiler.

// The result of "select PRICE from COFFEES" is a Seq of Double// because of the type safe column definitionsvalcoffeeNames:Seq[Double]=coffees.map(_.price).list// Query builders are type safe:coffees.filter(_.price<10.0)// Using a string in the filter would result in a compilation error

// Create a query for coffee names with a price less than 10, sorted by namecoffees.filter(_.price<10.0).sortBy(_.name).map(_.name)// The generated SQL is equivalent to:// select name from COFFEES where PRICE < 10.0 order by NAME

Other SQL databases can be accessed right away with a reduced feature set.
Writing a fully featured plugin for your own SQL-based backend can be achieved
with a reasonable amount of work. Support for other backends (like NoSQL) is
under development but not yet available.

Slick is released under a BSD-Style free and open source software license.
See the chapter on the commercial Slick Extensions add-on
package for details on licensing the Slick drivers for the big commercial
database systems.

The name Lifted Embedding refers to the fact that you are not working with
standard Scala types (as in the direct embedding)
but with types that are lifted into a Rep type
constructor. This becomes clear when you compare the types of a simple
Scala collections example

All plain types are lifted into Rep. The same is true for the table row
type Coffees which is a subtype of Rep[(String,Double)].
Even the literal 8.0 is automatically lifted to a Rep[Double] by an
implicit conversion because that is what the > operator on
Rep[Double] expects for the right-hand side. This lifting is necessary
because the lifted types allow us to generate a syntax tree that captures
the query computations. Getting plain Scala functions and values would not
give us enough information for translating those computations to SQL.