Core Concepts
When you use Slick, you start by composing Scala queries, then get actions (like “get results” or “insert data”) associated with these queries, and finally run the actions on a database to obtain results.
This chapter explains how these core concepts relate to each other and how they fit into your application design.
Scala Queries
The main type used by queries is Rep. A Rep[T] is a representation of a type T that
provides the necessary operations for building queries. Collection-valued queries are always of type
Query, which is a Rep of a collection type like Rep[Seq[Int]]. Queries can be composed
from representations of database tables (TableQuery), literal values and parameters. Query
composition does not require a database or execute any part of the query. It only builds a description of what to
execute at a later point.
Database I/O Actions
Operations that can be executed on a database are called database I/O actions (DBIOAction).
Several operations on queries and tables create I/O actions, for example myQuery.result,
myQuery.result.headOption, myQuery += data or myTable.schema.create. Actions can be composed with
combinators like andThen, flatMap, DBIO.seq or transactionally.
Just like a query, an I/O action is only a description of an operation. Creating or composing actions does not execute anything on a database. Combined actions always consist of strictly linear sequences of other actions. Parts of an action never run concurrently.
Plain SQL Statements
As an alternative to Scala queries you can write queries and other database statements in SQL. This is done with
string interpolators, for example sql"select id from mytable".as[Int] or
sqlu"insert into mytable (id) values (1)". These interpolators (in the case of sql with an extra .as call)
all produce database I/O actions.
Databases
A Database object encapsulates the resources that are required to
connect to a specific database. This can be just a number of connection parameters but in most cases it includes a
connection pool and a thread pool. You should usually create a single Database object when your application
starts and shut it down when your application shuts down to ensure that all resources are released.
Results
Any action can be run on a database to obtain the results (or perform side effects such as updating the database).
Execution is always asynchronous, i.e. it does not block the caller thread. Any kind of action can be run to obtain
a Future that is eventually completed with a result when the execution is finished (myDatabase.run(myAction)).
Actions that produce a sequence of values usually support streaming results as well. Such an action can be combined
with a database to produce a Reactive Streams Publisher (myDatabase.stream(myAction)). The action is
executed when a consumer subscribes to the Publisher.
Profiles
Even when using a standard interface for database drivers like JDBC there are many differences between databases in
the SQL dialect they understand, the way they encode data types, or other idiosyncracies. Slick abstracts over these
differences with profiles. Whenever you write queries (whether in Scala or SQL) or produce other database actions,
you need a concrete profile for your database. Usually these profiles extend the abstract JdbcProfile.
Database objects are interchangeable between all subtypes of JdbcProfile but they are usually configured together
with the profile because you need to pick the correct profile for the database.