J’ai longtemps cru que Scala ne me deviendrait jamais familier.

Pourtant, j’ai occupé de nombreuses soirées durant presque trois ans à lire plusieurs livres et dizaines d’articles de blog sur le langage, à voir des vidéos, assister à des conférences, et bien évidemment développer, de petits programmes dans un premier temps puis un gros projet qui m’occupe toujours aujourd’hui et qui devrait enfin voir le jour d’ici quelques semaines (j’aurai l’occasion d’en reparler ici). Je sentais durant tout ce temps mon niveau nettement s’améliorer, ma productivité s’accroître … mais le langage me paraissait toujours distant, comme une vieille connaissance qu’on cotoie depuis des années mais qui garde toujours sa part d’étrangeté, avec qui on peine toujours à trouver les mots justes pour dialoguer. La folle profondeur de Scala me donnait l’impression d’être face à un mur que je ne réussirais à franchir pour de bon qu’avec un déclic. Et ce déclic fut Slick.

Jusqu’à ce jour, l’essentiel de mon code Scala concernait Play! 2.

J’ai passé des centaines et centaines d’heures sur le framework et je pense le connaître raisonnablement bien aujourd’hui. J’ai appris à gérer le JSON, à utiliser les Future, les jobs Akka, les templates, etc. Mais qu’en est-il de la richesse du code Scala écrit ?

Du fait de la nature du site, qui est une webapp finalement assez simple, je n’ai hélas pas souvent eu l’occasion d’exploiter la richesse du langage. D’un côté, je prenais connaissance dans le livre d’Odersky des possibilités innombrables concernant le langage, de l’autre je devais me contenter d’Option, de map, de match, et autres trivialités (trivialités tout de même bienvenues lorsqu’on vient de Java). La base de données derrière le site a longtemps été MongoDB. Je gérais les accès avec le framework Salat, sur lequel j’ai un avis mitigé aujourd’hui. Il m’a été très utile dans certains cas mais globalement je trouve qu’il ajoute beaucoup trop de complexité inutile. Si c’était à refaire, j’opterais pour ReactiveMongo. Bref, tout tournait bien ainsi jusqu’à ce que le modèle de données se complexifie et que la nécessité de faire de vraies relations entre les collections apparaisse. Pour cela, le plus sage était de revenir à ce bon vieux SQL. Et donc d’apprendre à comment gérer au mieux les accès à une base de données relationnelle en Scala.

A la découverte des bibliothèques facilitant l’accès SGBD en Scala

Je tenais à faire les choses bien, mais surtout vite. Des années d’expérience sur de gros projets Java m’ont appris à me méfier des ORM type Hibernate. Je reconnais évidemment leur utilité dans certain cas, mais j’ai souvent trouvé leur utilisation trop systématique, évacuant trop rapidement des solutions plus légères et convenant mieux dans certains cas comme JDBCTemplate par exemple. J’ai donc été agréablement surpris de voir comme solution par défaut dans Play! Anorm, qu’on peut considérer comme une surcouche de JDBC. C’est clair, robuste, et ça demande d’écrire peu de code boilerplate. C’est la solution idéale dans le cas de petits projets. Mais dans mon cas, entités complexes oblige, je souhaitas avoir un peu plus. Je me suis donc tourné vers l’autre framework majeur, à savoir Slick, autrefois ScalaQuery.

Slick n’est pas la bibliothèque par défaut dans Play! mais je suppose qu’il pourrait le devenir à terme dans le sens où il fait partie de la stack TypeSafe. Afin de bien intégrer Slick à mon projet, j’ai choisi d’utiliser le framework play-slick, qui fait de Slick un first-citizen de Play! en l’intégrant à son coeur, en lui faisant profiter de ce qu’il apporte au niveau de la gestion des session, des connexions, etc, et en le liant aux “Models” définis. Ce plugin est très peu intrusif et apporte beaucoup tout en laissant Slick libre. Une fois configuré on peut donc se contenter de la documentation Slick pour développer, le code Slick en tant que tel n’est pas influencé.

Les mains dans le moteur

Sur ce, venons-en à Slick avec un exemple simple. Imaginons un blog multi-auteurs très sommaire, avec deux entités seulement : Author et Article. Un Author est défini par son id (author_id - clé primaire), son nom (last_name) et son prénom (first_name) Un Article est défini par son id (article_id - clé primaire), son titre (title), son contenu (content) et son auteur (author_id - clé étrangère).

Le mapping objet/table en tant que tel est très simple et classique.

Commençons par l’objet Author.

{% highlight java %} case class Author( id: Option[Int] = None, lastName: String, firstName: String )

class Authors(tag: Tag) extends TableAuthor {

def id = column[Int]("author_id", O.PrimaryKey, 0.AutoInc)

def lastName = column[String]("last_name")

def firstName = column[String]("first_name")

def * = (
    id.?,
    lastName,
    firstName) <> (Author.tupled, Author.unapply _
)

}

val authors = TableQuery[Authors]

{% endhighlight %}

Quelques remarques à propos de ce code :

• J’ai choisi directement de mapper mon modèle (défini par une case class) à la table (“extends Table[Author]")

• L’attribut “id” d’Author est défini comme Option en vue des futurs inserts étant donné que sa valeur n’est pas connue à l’avance, du fait de sa nature de champ incrémenté (cf. l’attribut “0.AutoInc”). Ce champ n’étant évidemment pas optionnel en base de donnée, il ne devait pas être déclaré comme tel, d’où le def id = column[Int] et non def id = column[Option[Int]]. C’est au niveau de la projection que le mapping “not null => option” se fait, avec l’ajout de l’attribut “.?” au champ id (“id.?")

L’objet Article suit une logique similaire.

{% highlight java %} case class Article( id: Option[Int] = None, title: String, content: String, date: Date, authorId: Int )

class Article(tag: Tag) extends TableArticle {

def id = column[Int]("article_id", O.PrimaryKey, 0.AutoInc)

def title = column[String]("title")

def content = column[String]("content")

def date = column[Date]("date")

def authorId = column[Int]("authorId")

def author = foreignKey("authorFk", authorId, Authors.Authors)(_.id)

def * = (
    id.?,
    title,
    content,
    date,
    authorId) <> (Article.tupled, Article.unapply _
    )

}

val articles = TableQuery[Articles] {% endhighlight %}

La nouveauté ici réside dans la présence d’une clé étrangère sur la classe Author. Vous noterez que dans la définition d’Article, seul un attribut AuthorId de type Int est présent. Il n’y a pas directement d’attribut de type Author. C’est en effet quelque chose de déconseillé par Slick qui recommande plutôt de résoudre ce mapping directement dans les requêtes (nous verrons plus tard comment). C’est un point qui m’a surpris au début, étant habitué au mapping objet total proposé par Hibernate.

Venons en maintenant à l’écriture des requêtes proprement dites, que je choisis de placer dans un objet compagnon (“object Articles”, “object Authors”). Commençons simplement ; comment chercher un article par son ID ?

{% highlight java %} def findById(id: Long) = Articles.where(_.id === id) {% endhighlight %}

Si on n’est pas sûr d’obtenir un résultat (ce qui est plus sage !) :

{% highlight java %} def findById(id: Long) = Articles.where(_.id === id).firstOption {% endhighlight %}

Si souhaite plusieurs résultats : {% highlight java %} def findByFirstName(firstName: String) = Authors.where(_.firstName === firstName).list {% endhighlight %}

C’est simplissime et ça fait pourtant tout ce qu’on lui demande, sans pourtant s’être prémuni d’une machine de guerre. Pour rappel, avec la Criteria API de JPA, ça donnerait :

{% highlight java %} CriteriaQuery q = cb.createQuery(Author.class); Root author = q.from(Author.class); q.where(cb.equal(author.get(Author_.firstName), firstName)); {% endhighlight %}

Mais ces cas-là ne sont pas je vous l’accorde forcément intéressants. Comment ajouter un ordre de tri par date à la liste d’Articles retournés ?

{% highlight java %} def findById(id: Long) = Articles.where(.id === id).sortBy(.date).list {% endhighlight %}

Avec la Criteria API : {% highlight java %} CriteriaQuery