This Knolx session is all about Slick, a library for accessing relational databases using an interface similar to the Scala collections library. Through this session, we'll get familiar with slick and how it's better than ORMs. We'll learn how we map Scala datatypes with the relational database in slick, covering most of the basics here and give you everything you need to be productive with the library through a short demo. The agenda of the session is: ~ What is Slick ~ Features of Slick ~ ORM vs Slick ~ Some Core Concepts ~ How Mapping Occurs? ~ SQL vs Slick Examples ~ Benefits of Slick ~ Supported Databases

1. Megha Jatana
Software Consultant
Knoldus Inc.
Let’s take a Deep
Dive into Slick

2. Lack of etiquette and manners is a huge turn off.
KnolX Etiquettes
Punctuality
Respect Knolx session
timings, you are requested
not to join sessions after a 5
minutes threshold post the
session start time.
Feedback
Make sure to submit a
constructive feedback for all
sessions as it is very helpful
for the presenter.
Silent Mode
Keep your mobile devices in
silent mode, feel free to
move out of session in case
you need to attend an
urgent call.
Avoid Disturbance
Avoid unwanted chit chat
during the session.

3. Some Core Concepts
How Mapping Occurs?
Supported Databases
Benefits of Slick
SQL vs Slick Examples
OUR AGENDA
01
`
What is Slick
02
03
04
05
06
07
Features of Slick
08
ORM vs Slick

4. SLICK

5. What is Slick?
● A database library
● Not an ORM
● Functional
● Asynchronous

6. Key Features
● Static checking
● Type safe
● Composable Queries

7. ORM vs Slick
● Slick is configured using small
amounts of Scala code. In Slick
you provide it as Scala types
which are used to type-check
Slick queries.
● Slick doesn’t cache query results.
Working with Slick is like working
with JDBC in this regard.
It is very clear that executing a
query leads to a database round
trip .
● ORMs use extensive configuration files.
In ORMs you often provide your
mapping specification in a
configuration file.
● Many ORMs come with read and write
caches. Caches are side-effects. They
can be hard to reason about. It can be
tricky to manage cache consistency
and lifetime.
This call may be served from the
database or from a cache

8. ORM vs Slick
● To avoid stateful caches and
mutability, Slick handles relationship
manipulations just like SQL - using
foreign keys. Changing relationships
means updating foreign key fields
to new ids, just like updating any
other field. As a bonus this allows
establishing and removing
associations with objects that have
not been loaded into memory.
Having their ids is sufficient.
● When manipulating relationships
with ORMs you usually work on
mutable collections of associated
objects and inserts or remove
related objects. Changes are written
to the database immediately or
recorded in a write cache and
committed later.

9. Some Core Concepts
● Tables
● Queries
● Actions
● Joins
● Profiles
● Databases
● Results

10. Some Core Concepts

11. Mapping in slick
Let’s understand FRM mapping in slick using following database
schema

12. Mapping in slick

13. Demo

14. SQL vs Slick Examples
Let’s take an overview over the most important types of
SQL queries and a corresponding type-safe Slick query.
● select *
● where

15. SQL vs Slick Examples
● order by
● group by
● having

16. SQL vs Slick Examples
● insert
● update
● delete

17. Slick Benefits
● Don’t have to write SQL queries
● Benefit from compile time error checking.
● Protection against SQL Injection

18. Supported Databases
● DB2
● Derby / JavaDB
● H2
● HSQLDB (HyperSQL)
● Microsoft SQL Server
● MySQL
● Oracle
● PostgreSQL
● SQLite
[NOTE: Support for other backends (like NoSQL) is under development but
not yet available.]

19. Q/A

20. ● https://scala-slick.org/doc/3.3.2/
● https://books.underscore.io/essential-slick/essential-slick-3.html
● https://github.com/shekhargulati/52-technologies-in-2016/tree/mas
ter/04-slick
References

21. Thank You !