Et si on changeait l’ORM de Ruby on Rails ?

Sequel (lien)

Sequel est un ORM qui ressemble beaucoup à Active Record. Il semble globalement faire la même chose :
– l’écriture des migrations ressemble à AR mais s’écrit un peu différemment
– la syntaxe des associations dans les modèles ressemble à AR mais s’écrit un peu différemment
– la syntaxe de chainage ressemble à AR mais s’écrit un peu différemment

Des variations mineures existent. Exemple, Sequel permet de créer des clés étrangères SQL, donnant à un .destroy la capacité de supprimer les liaisons via

En revanche, Sequel permet de faire des jointures via les méthodes suivantes :
join, inner_join, full_outer_join, right_outer_join, left_outer_join, full_join, right_join et left_join.
Non seulement ce n’est pas possible avec ActiveRecord en Rails 4, mais Rails 5 n’apporte rien de plus que le OR alors que c’était loin d’être la seule lacune de l’ORM. La limitation semble provenir d’Arel, bibliothèque sur laquelle AR repose. Dans le cas de jointures autres que INNER JOIN et LEFT OUTER JOIN, il ne semble pas y avoir d’autre solution que de devoir perdre l’abstraction de l’ORM en écrivant à nouveau du code SQL.

Quand on sait utiliser Active Record, le gain est faible à passer de l’un à l’autre, sauf à considérer ce gain comme un besoin central. Sequel est activement développé et évolue continuellement. Sans expérience préalable sur Sequel, je ne saurais trancher entre les deux ORM pour débuter un projet.

DataMapper (lien)

Ce projet est abandonné depuis 2011.

Ruby Object Mapper (lien)

Au détour d’un article, j’ai pu lire que ROM était la v2 de DataMapper. C’est un ORM mettant un accent fort sur la séparation entre les objets et les données. ROM le définit dans ces termes (traduction) :

ROM utilise des adapters pour se connecter à différentes sources de données (une base de données, un fichier CSV, ça n’a pas d’importance) et expose une interface CRUD native à ses relations. Chaque adapter a des points d’extension pour supporter les fonctionnalités spécifiques [de votre source de donnée]. Il fournit ses propres types de relations, extensions de commandes pré-intégrées, et potentiellement de nouveaux types de commandes. De plus, un adapter fournit des fonctionnalités supplémentaires qui sont requises pour travailler avec un type de source de données particulier. Par exemple, rom-sql apporte une Migration API.

À noter que les couches créant une correspondance entre source de donnée et objet peuvent être ajoutées manuellement pour utiliser toute nouvelle source qui n’existerait pas encore. La comparaison de ROM avec ActiveRecord indique :
– que ROM supporte en plus de SQL les bases NoSQL (CouchDB, MongoDB et Cassandra), des fichiers (CSV et Yaml), des API HTTP distantes, créer notre propre source de données, voire combiner plusieurs sources à la fois (il existe d’autres adapters qui ne sont pas prêts pour la production)
– il n’y a pas de réelle représentation de la sourcée de donnée via de modèles, les objets ROM n’ont pas de notion de persistance, il n’y a pas de système de validation natif (comme avec Sequel, une gem le fait)

À l’utilisation, ROM se compare aux scopes ActiveRecord.

Performances

Les développeurs et les admins sys adorent les benchmarks. Le problème : beaucoup observent le test sous l’angle favorisant l’un ou l’autre. Les tests datent parfois un peu, et dans un monde en perpétuel développement je n’en ai pas trouvé qui reflète la réalité à la date d’écriture de cet article (rien dans le courant de l’année).

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.