La version 2.0 de SQLAlchemy, l’outil open source SQL écrit en Python, est disponible

La version 2.0 de SQLAlchemy, l’outil open source SQL et un mapping objet-relationnel écrit en Python, est disponible,
elle apporte le support pep-484 pour les requêtes ORM

L’équipe en charge de SQLAlchemy, l’outil open source SQL et un mapping objet-relationnel écrit en Python et publié sous licence MIT, est à sa verion 2.0. SQLAlchemy a opté pour l'utilisation du pattern Data Mapper plutôt que l'active record utilisés par de nombreux autres ORM. Avec cette version, la version par défaut de SQLAlchemy qui sera installée lorsqu'on exécutera pip install sqlalchemy sera la version 2.0.

SQLAlchemy est la boîte à outils Python SQL et le mappeur objet-relationnel qui offre aux développeurs d'applications toute la puissance et la flexibilité de SQL. SQLAlchemy fournit une suite complète de modèles de persistance bien connus et conçus pour un accès efficace et performant aux bases de données, adaptés dans un langage de domaine simple et pythonique.

Notons que la version 2.0 comporte des modifications importantes de l'API par rapport à la série 1.4. Les applications qui fonctionnent avec la série 1.x de SQLAlchemy et qui n'ont pas suivi le processus de migration doivent donc s'assurer que les exigences sont définies pour maintenir en place la série de versions majeures de SQLAlchemy souhaitées.

Pièce jointe 634333

Fonctionnalités de SQLAlchemy

Un ORM industriel, construit à partir du noyau sur les patterns identity map, unit of work, et data mapper. Ces modèles permettent une persistance transparente des objets en utilisant un système de configuration déclaratif. Les modèles de domaine peuvent être construits et manipulés naturellement, et les changements sont synchronisés automatiquement avec la transaction en cours.

Un système de requête orienté relationnel, exposant explicitement la gamme complète des capacités de SQL, y compris les jointures, les sous-requêtes, la corrélation et presque tout le reste, en termes de modèle objet. L'écriture de requêtes avec l'ORM utilise les mêmes techniques de composition relationnelle que vous utilisez lorsque vous écrivez du SQL. Bien que vous puissiez passer au SQL littéral à tout moment, cela n'est pratiquement jamais nécessaire.

Un système complet et flexible de chargement rapide pour les collections et les objets liés. Les collections sont mises en cache dans une session et peuvent être chargées lors d'un accès individuel, en une seule fois à l'aide de jointures, ou par requête par collection sur l'ensemble des résultats.

Un système de construction Core SQL et une couche d'interaction DBAPI. Le noyau SQLAlchemy est distinct de l'ORM et constitue une couche d'abstraction de base de données à part entière. Il comprend un langage d'expression SQL extensible basé sur Python, des métadonnées de schéma, un pool de connexion, une coercition de type et des types personnalisés.

Toutes les contraintes de clés primaires et étrangères sont supposées être composées et naturelles. Les clés primaires entières de substitution sont bien sûr toujours la norme, mais SQLAlchemy ne suppose jamais ce modèle et ne le code pas en dur.

Introspection et génération de bases de données. Les schémas de base de données peuvent être "reflétés" en une seule étape dans des structures Python représentant les métadonnées de la base de données ; ces mêmes structures peuvent ensuite générer des instructions CREATE - tout cela dans le Core, indépendamment de l'ORM.

SQLAlchemy, une séparation en deux phases majeures

L'histoire de la série SQLAlchemy 2.0 commence il y a plus de quatre ans, le 8 août 2018, avec quelques brèves idées sur la façon dont la notion de requête Core et ORM de SQLAlchemy pourrait être unifiée. Le premier plan pour un véritable concept de « SQLAlchemy 2.0 » s'est formé en novembre de la même année, et s'est concentré sur les deux domaines de simplification drastique de l'exécution de Core et des API transactionnelles, ainsi que sur la recherche d'une unification de l'interrogation à travers Core et ORM. Selon l’équipe en charge, les changements apportés aux concepts fondamentaux étaient suffisamment importants pour que SQLAlchemy 2.0 soit séparé en deux phases majeures.

La première phase était la série SQLAlchemy 1.4, qui fournissait un système d'interrogation SQL Core / ORM entièrement unifié, tout en s'appuyant sur une nouvelle architecture universelle de mise en cache des instructions. Cette phase a fourni l'implémentation complète de l'approche de construction SQL de SQLAlchemy 2.0 (sans le support du typage pep-484), tout en maintenant complètement l'ancienne API de requête. Avec cette version, un chemin de migration complet inspiré des leçons tirées du processus de migration de Python 2->3 a été fourni, qui décrit comment porter les applications afin qu'elles puissent continuer à fonctionner dans SQLAlchemy 1.4 tout en étant entièrement compatibles avec SQLAlchemy 2.0.

La deuxième phase est la série SQLAlchemy 2.0, qui supprime la majorité des éléments dépréciés, reléguant les autres (principalement Query) au statut d' « héritage » à long terme, passe complètement à Python 3 uniquement, et ajoute en même temps de nombreuses nouvelles fonctionnalités qui s'appuient sur la nouvelle architecture, en tirant pleinement parti des fonctionnalités de Python 3 (notamment les classes de données, les enums, les annotations en ligne) ainsi que de la nouvelle architecture de requête unifiée.

Le principal avantage de cette approche est que les changements architecturaux les plus importants et de loin les plus risqués, à savoir la réécriture des requêtes Core/ORM au-dessus d'une nouvelle couche de mise en cache, sont déjà utilisés en production avec SQLAlchemy 1.4 depuis près de deux ans. Ainsi, alors que SQLAlchemy 2.0 aura certainement beaucoup de nouveaux problèmes une fois qu'il sera utilisé par l'ensemble des développeurs, ils ne devraient pas être du type « nouvelles fissures dans l'approche fondamentale », car les bases architecturales sont déjà largement utilisées.

SQLAlchemy 2.0 est une version suffisamment importante pour faire l'objet de deux guides de migration : le guide de migration majeure explique comment assurer la compatibilité des API pour qu'une application puisse fonctionner dans SQLAlchemy 1.4 ou 2.0 ; le guide What's New in SQLAlchemy 2.0 ? présente toutes les nouvelles fonctionnalités et API disponibles une fois qu'une application fonctionne dans SQLAlchemy 2.0.

Liste de ce qui est totalement nouveau dans SQLAlchemy 2.0

Toutes les nouvelles syntaxes ORM compatibles avec pep-484 sans plugin : le style déclaratif ORM de configuration de mappeur a maintenant un tout nouveau look, empruntant fortement à des systèmes tels que Python dataclasses et SQLModel pour fournir des déclarations ORM axées sur les annotations, en utilisant l'interprétation à l'exécution des annotations pep-484 pour produire des classes mappées qui sont entièrement typées et compatibles avec n'importe quel vérificateur de type ou IDE.

Support pep-484 pour les requêtes ORM de type nouveau et ancien : en utilisant les modèles déclaratifs annotés, les constructions SQL que l'on crée, telles qu'un objet select() ou une construction Query ancienne, sont elles-mêmes typées quant au type de colonnes retournées dans une ligne, et ce typage se poursuit jusqu'aux valeurs Python extraites de l'objet résultat retourné après exécution de la requête.

Alors que le typage Python a encore des limites pour faire ce genre de choses, le nouveau support de typage s'inspire de certaines techniques utilisées par SQLModel de sorte qu'il fonctionne sans annotations supplémentaires pour la grande majorité des requêtes générées à partir de classes de modèles ORM, avec des degrés variables de support pour le typage des ensembles de résultats des requêtes orientées Core ou hybrides Core/ORM. Quelques exemples sont disponibles sur le site SQL Expression Typing – Examples.

Déclarative entièrement intégrée aux classes de données Python - SQLAlchemy 2.0 introduit la prise en charge d'une classe mappée Déclarative Annotée qui peut être générée directement en tant que classe de données Python ; cela permet d'obtenir une classe mappée ORM déclarée comme n'importe quelle autre classe, avec des méthodes de classes de données générées automatiquement, telles que __init__(), __repr__(), __eq__(), et tout le reste. Cette nouvelle approche est largement améliorée par rapport aux approches "hybrides" provisoires introduites dans SQLAlchemy 1.4.

Une toute nouvelle approche de l'INSERT en masse, entièrement intégrée à l'ORM, qui est généralement plus rapide d'un ordre de grandeur sur la plupart des backends - La plupart des bases de données et des pilotes pris en charge par SQLAlchemy ont désormais ajouté ou amélioré leur prise en charge de la syntaxe INSERT RETURNING, et SQLAlchemy 2.0 en a profité pour prendre en charge et améliorer la prise en charge du RETURNING pour tous ses backends, à la seule exception de MySQL (MySQL uniquement ; MariaDB prend en charge le RETURNING).

Une partie de cette amélioration réside dans la possibilité d'insérer des milliers de lignes en une seule instruction par lots qui renvoie également un ensemble complet de valeurs générées par le serveur et nécessaires à l'ORM, ce qui n'était jamais possible auparavant, à la seule exception d'une implémentation provisoire qui reposait sur le pilote psycopg2. Dans la version 2.0, le travail a été fait pour optimiser INSERT pour tous les backends de sorte que des milliers d'objets ORM avec ou sans clés primaires peuvent être INSERTS en un seul aller-retour de la base de données, et cette capacité est entièrement intégrée dans l'ORM pour toutes les opérations INSERT, à la fois pour les opérations ORM "régulières" en unité de travail et pour les approches "en masse", qui sont également nouvellement révisées dans la version 2.0.

Une toute nouvelle architecture de réflexion des schémas optimisée en masse : les opérations qui reflètent des schémas complets en une seule fois, telles que MetaData.reflect(engine), et les opérations à l'échelle du schéma nouvellement ajoutées avec la construction inspect(engine) reposent désormais sur une base qui suppose des opérations qui fonctionnent sur des centaines ou des milliers de tables en une seule fois, plutôt que sur une table à la fois. Les dialectes peuvent "opter" pour la nouvelle architecture en fournissant de nouvelles requêtes de réflexion qui fonctionnent sur de nombreuses tables à la fois, ce qui permet aux très grands schémas d'être entièrement reflétés de manière beaucoup plus efficace.

La nouvelle architecture est activée pour les backends PostgreSQL et Oracle, qui étaient les deux backends présentant les plus gros problèmes de performance pour les grands schémas, où elle accorde une amélioration de 250 % pour PostgreSQL et de 900 % pour Oracle. Le dialecte SQL Server est la prochaine cible de la nouvelle architecture. Tout dialecte tiers peut opter pour le nouveau système "plusieurs tables à la fois" ou rester sur l'ancienne approche "table à la fois" qui reste complètement compatible sans aucun changement.

Extensions natives portées vers Cython : les extensions C de SQLAlchemy ont été remplacées par une approche actualisée utilisant Cython. La version Cython des extensions est dans la plupart des cas aussi rapide, et parfois plus rapide, que les anciennes extensions C, et permet à SQLAlchemy de fournir de nouvelles extensions natives dans plus de domaines de la bibliothèque beaucoup plus facilement sans risque de problèmes de mémoire ou de stabilité.

La philosophie de SQLAlchemy

Les bases de données SQL se comportent de moins en moins comme des collections d'objets au fur et à mesure que la taille et les performances deviennent importantes ; les collections d'objets se comportent de moins en moins comme des tables et des lignes au fur et à mesure que l'abstraction devient importante. SQLAlchemy vise à tenir compte de ces deux principes.

Un ORM n'a pas besoin de cacher le "R". Une base de données relationnelle fournit des fonctionnalités riches, basées sur des ensembles, qui doivent être pleinement exposées. L'ORM de SQLAlchemy fournit un ensemble ouvert de modèles qui permettent à un développeur de construire une couche de médiation personnalisée entre un modèle de domaine et un schéma relationnel, transformant ainsi le problème dit de "l'impédance objet-relationnel" en un lointain souvenir.

Dans tous les cas, le développeur prend toutes les décisions concernant la conception, la structure et les conventions de nommage du modèle objet et du schéma relationnel. SQLAlchemy ne fournit que les moyens d'automatiser l'exécution de ces décisions.

Avec SQLAlchemy, on ne peut pas dire que « l'ORM a généré une mauvaise requête » - vous gardez le contrôle total de la structure des requêtes, y compris la façon dont les jointures sont organisées, la façon dont les sous-requêtes et la corrélation sont utilisées, les colonnes demandées. Tout ce que fait SQLAlchemy est en fin de compte le résultat d'une décision prise par le développeur.

N'utilisez pas un ORM si le problème n'en a pas besoin. SQLAlchemy se compose d'un noyau et d'un composant ORM distinct. Le Core offre un langage d'expression SQL complet qui permet la construction pythonique de constructions SQL qui se traduisent directement en chaînes SQL pour une base de données cible, renvoyant des ensembles de résultats qui sont essentiellement des curseurs DBAPI améliorés.

Les transactions devraient être la norme. Avec l'ORM de SQLAlchemy, rien n'est stocké de manière permanente avant l'appel de commit(). SQLAlchemy encourage les applications à créer un moyen cohérent de délimiter le début et la fin d'une série d'opérations.

Ne rendez jamais une valeur littérale dans une instruction SQL. Les paramètres liés sont utilisés dans la mesure du possible, ce qui permet aux optimiseurs de requêtes de mettre en cache les plans de requêtes de manière efficace et de faire en sorte que les attaques par injection SQL ne soient pas un problème.

:fleche: Télécharger SQLAlchemy 2.0.0 ici

Source : SQLAlchemy

Et vous ?

:fleche: Quel est votre avis sur le sujet ?

Voir aussi :

:fleche: La version 2.0 d'Automerge, un CRDT qui permet d'enregistrer les modifications apportées aux données, est disponible, avec des améliorations de performance et de fiabilité

:fleche: HC-tree, un dorsal expérimental de base de données haute-concurrence pour SQLite, il vise à développer un nouveau module de base de données qui améliore SQLite

:fleche: Elastic annonce des améliorations pour la recherche et la réplication inter-clusters : une résilience accrue, une latence réduite, et accès aux données dans les environnements sur site et cloud