IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bruno

183PARTAGES

9  0 
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.


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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !