The slides of my presentation for Scala Amsterdam on functional programming with database side effects. Given on May 7th 2015

1. Slick 3.0: Functional
programming with
database side effects
(On short notice…)
Joost de Vries
twitter: @jouke
email: joost@de-vries.name
codestar.nl
github: joost-de-vries

2. ๏ Database actions in Slick 3.0
• Actions in FP: side effects
• A lightweight database action implementation
• Database actions in Slick 3.0 revisited

3. What is Slick
• Slick is originally a Scala framework that offers
flatmappable relational queries
• Comparable to Microsofts Linq to Sql
• Blocking, thread based

4. var xs = array.Where(x => x >= 1); array filter { _ >= 1 }
var xs = array.Select(x => x + 1); array map { _ + 1 }
var yx = array.SelectMany(x => new
[] { x, 3 });
array flatMap { Array(_, 3) }
var results =
from x in array
where x >= 1
select x;
for (x <- array if x >= 1)
yield x
LINQ to Sql: SQL as map, flatmap & filter
Slick offers the same paradigm in Scala
JOOQ is an alternative to Slick for the JVM
This talk is not about SQL querying using map and flatmap

5. What’s new in Slick 3.0
• Non blocking
• (Or is it?)
• Source for reactive streams

6. DBIO[A] (non streaming)
From: Hello Slick 3.0 example project

7. A DBIO[R] (simplified)

8. Type hierarchy

9. Type hierarchy

10. Reactive streams
The goal

12. Reactive streams feature pure functions
to process a stream of events
back pressure
“asynchronous computations that allow separating cpu
intensive code from IO intensive code”
So we need a way to deal with db
side effects in a purely functional
way

13. FP vs side effects
• Db manipulation is all about side effects
• So how do you deal with side effects in a purely
functional programming model?
• Using flatmappable ‘actions’

14. • Database actions in Slick 3.0
๏ Actions in FP: side effects
• A lightweight database action implementation
• Database actions in Slick 3.0 revisited

15. functional stream processing
• Remember we wanted to let db manipulation
take part in the purely functional world of stream
computing
• Hence we need a flatmappable way of dealing
with side effects

16. Functional stream
processing
• In Scala we’re used to flatmappables for
• Null values
• Exceptions
• Latency
• Collections
• But not for
• Input / Output
• Reading from an environment
• Mutating state
I.e. managing side effects

17. The power of semi colons!
Great for side effects but not streamable

18. What’s so great about
supporting flatmap?
• Put building blocks together into bigger building
blocks
• Alternate outcomes are transparantly
propagated through parts to the whole
• … depending on the instance

19. Chaining outcomes in Swift

20. • Pure functions don’t have side effects
• I.e. a function evaluation has always the same
value
• (a.k.a. Substitution principle, referential
transparency)
• But a program without f.i. IO is useless

21. How does Haskell handle
side effects?
• Haskell is a pure lazy language
• There’s no ; operator to evaluate sequentially
• To do IO so called actions are used:
recognisable from the their type

22. So writing hello
world is in Haskell not
the first thing you do

23. Spot the side effect
def f : Unit => A
def g: A => Unit
f
A
?
g
A
?

24. Actions
• A value of type IO t is an action that, when
performed, may do some input/output before
delivering a result of type t.
• Actions are also called computations
• Evaluating an action has no effect; performing
an action has effect.
• Actions can be put together into bigger actions
Source: Simon Peyton Jones - Lazy functional
programming for real

25. Function declaration: type
Function implementation

26. Haskell to Scala translation

27. Actions…
Our building blocks

28. Chaining actions into a
programme
The type of >>= :
() means: infix operator (ignore the ‘ accent)
flatmap in Scala
meaning is similar to ; in Scala

29. Chaining actions into a
programme
In the FP world this is called ‘composition’;
‘composing’ 3 flatmappables into a composite
action
type IO a = World -> (a, World)

30. Ignore the result of a
previous action
Pronounced as andThen

32. • Database actions in Slick 3.0
• Actions in FP: side effects
๏ A lightweight database action implementation
• Database actions in Slick 3.0 revisited

33. Resource mgmt with
functions
In the early days of the Spring
framework it provided this as
JdbcTemplate

34. From: 2012 talk by Paul Chuisano

35. Let’s flatmap that

36. [coding]

37. Putting actions together into
bigger actions

39. The Reader flatmappable
Anything that takes a context like object to
create results is a candidate for a Reader type
of flat mappable

41. • Database actions in Slick 3.0
• Actions in FP: side effects
• A lightweight database action implementation
๏ Database actions in Slick 3.0 revisited

42. DBIO[A] (non streaming)

43. StreamingDBIO

44. Type of materialised
result
Read and/or Write side
effect for master/slave
routing
Type of streamed
elements

45. Client code is run in client execution context
DB code is run against dedicated thread pool
Separated!

46. Resources
• Stefan Zeigers talk at Scala Days San Fransisco
• slides http://slick.typesafe.com/talks/scaladays2015sf/
Reactive_Slick_for_Database_Programming.pdf
• video https://www.parleys.com/tutorial/reactive-slick-
database-programming
• Paul Chiusano and Rúnar Bjarnason - Functional programming
in Scala
• Activator template hello-slick-3.0

47. • Let’s take a short break and start hacking!
• The idea is to enhance a scala application that
uses Slick and deploy it to Heroku to
demonstrate.
• If you’ve forwarded your github handle I’ll add
you to the project repo.
• The repo code is for todays use only. Please be
responsible and don’t put it on the public
internet somewhere.