Slick, la bibliothèque d'accès et d’interrogation de base de données de Typesafe en Scala, a reçu une refonte majeure avec la publication de sa dernière version 3.0. Également surnommée "Slick réactive", elle introduit une nouvelle API pour composer et exécuter des requêtes en base de données de manière réactive. Réactive dans le sens qu'elle prend en charge l'API Reactive-Streams, une « initiative permettant de fournir une norme pour les traitements des flux de manière asynchrone et non bloquante avec contre-pression" (d'autres implémentations comprennent Akka, MongoDB, RxJava, Vert.x, etc.) et qui prend en charge le développement des applications conformément au manifest réactif.
Les requêtes en base de données avec Slick peuvent être écrites comme si elles opéraient sur des collections Scala, en soutenant le même vocabulaire et les opérations similaires (même si cette illusion échoue sur des expressions plus complexes). En plus, comme les requêtes ne sont pas seulement des chaînes de caractères simples, la vérification des types est effectuée à la compilation. Voici un exemple d'une simple jointure entre deux tables avec la clause where :
val q2 = for {
c <- coffees if c.price < 9.0
s <- suppliers if s.id === c.supID
} yield (c.name, s.name)
Le code SQL équivalent pourrait ressembler à :
select c.COF_NAME, s.SUP_NAME from COFFEES c, SUPPLIERS s where c.PRICE < 9.0 and s.SUP_ID = c.SUP_ID;
Alors que l'API de requêtage est restée largement inchangée dans Slick 3, désormais la requête renvoie un DBIOAction au lieu du résultat réel (les anciennes API sont obsolètes et seront supprimées en 3.1). Ces actions peuvent ensuite être combinées et à la fin sont passées à la base de données, où elles finiront par être exécutées. Voici un exemple d'une telle requête de style Slick 3 :
val q = for (c <- coffees) yield c.name
val a = q.result
val f: Future[Seq[String]] = db.run(a)
f.onSuccess { case s => println(s"Result: $s") }
Par rapport à l’API précédente :
val q = for (c <- coffees) yield c.name
val result = db.withSession {
implicit session =>
val s = q.list // <- takes session implicitly
println(s"Result: $s")
}
Le principal avantage de la nouvelle approche est qu'elle est complètement asynchrone, l'exécution de la requête sur la base de données ne bloque pas le thread appelant. En outre, les résultats de la base de données peuvent désormais être diffusés en continu. A titre d’exemple, en combinaison avec le framework Play qui prend en charge les reactive-streams, cela permet de libérer le thread de traitement des demandes aussi rapidement que possible.
InfoQ a parlé avec Stefan Zeiger, le Tech-Lead de Slick, pour en savoir plus sur la nouvelle version et leurs plans pour l'avenir.
InfoQ : La nouvelle API semble affecter surtout comment les requêtes sont gérées. Y a-t-il eu des changements dans la façon dont les requêtes sont construites ?
Il n'y a pas de changements fondamentaux dans la manière dont vous écrivez vos requêtes, mais il y a deux grandes nouvelles fonctionnalités. La première sont les jointures externes qui sont désormais correctement typées, retournant une Option d’un côté (ou les deux dans le cas d'une jointure externe complète). Cela rend les jointures externes avec des types de données mappées ou sur plus de deux tables, simple à écrire, où vous deviez précédemment effectuer des mappings non évidents et non triviaux dans chaque requête. L'autre grande caractéristique est l’interpolateur tsql qui permet la vérification statique et l'inférence de type pour les instructions SQL imbriquées. Au lieu d'attendre jusqu'à l'exécution pour découvrir les erreurs dans le code SQL écrit à la main, le compilateur Scala peut désormais déléguer à la base de données les contrôles au moment de la compilation.
InfoQ : Avez-vous des plans pour développer une API Java pour Slick qui rend l'utilisation des nouveautés Streams et Lambdas de Java 8, similaire aux APIs Java de Play ou de Akka ?
Oui, cela fait partie des choses que nous aimerions faire dans un futur proche afin de compléter notre solution full-stack pour les développeurs Java.
InfoQ : Est-ce que le streaming et la nouvelle IO-API fonctionnent sur toutes les bases de données, ou y a-t-il des limites ?
L'API DBIO est mise en œuvre au-dessus de JDBC et fonctionne avec tous les pilotes existants. Nous étudions également l’amélioration du support natif pour les bases de données avec les pilotes asynchrones existants.
InfoQ : Pouvez-vous partager vos plans pour Slick 3.1 ou 4.0 ?
La caractéristique majeure sur laquelle on travaille actuellement pour Slick 3.1 est l’amélioration du compilateur des requêtes back-end, ce qui va permettre de générer un code SQL plus simple. Cela va rendre le code généré plus lisible pour tous les utilisateurs et devrait également fournir des améliorations de performance, en particulier sur MySQL où les jointures telles qu'elles sont actuellement générées par Slick, ne peuvent souvent pas utiliser les indexes. Dans le cadre de notre offre commerciale dans la plateforme réactive, nous allons ajouter la fonctionnalité de surveillance spécifiquement pour Slick.
Pour la liste complète des modifications, consultez l'annonce de publication et n’oubliez pas de vérifier le guide de mise à niveau. Pour en savoir plus à propos de Slick 3, regardez la présentation de Stefan Zeiger au ScalaDays.