Je suis nouveau à la fois dans flask et sqlalchemy, je viens de commencer à travailler sur une application flask, et j'utilise sqlalchemy pour le moment. Je me demandais s'il y avait un avantage significatif à utiliser flask-sqlalchemy plutôt que sqlalchemy. Je n'ai pas trouvé suffisamment de motivations dans http://packages.python.org/Flask-SQLAlchemy/index.html ou peut-être que je n'ai pas compris la valeur ! !! J'apprécierais vos éclaircissements.
Réponses
Trop de publicités?La principale caractéristique de l Flask-SQLAlchemy
est une intégration correcte avec l'application Flask - elle crée et configure le moteur, la connexion et la session et les configure pour fonctionner avec l'application Flask.
Cette configuration est assez complexe, car nous devons créer le fichier session scopée et le traiter correctement selon le cycle de vie des demandes et des réponses de l'application Flask.
Dans un monde idéal, ce serait la seule caractéristique de l'entreprise. Flask-SQLAlchemy
mais en réalité, il ajoute quelques éléments supplémentaires. Regardez les docs pour plus d'informations. Vous pouvez également consulter cet article de blog qui en donne un aperçu : Démystifier Flask-SQLAlchemy (mise à jour : l'article original n'est pas disponible pour le moment, il y a une instantané sur webarchive ).
Lorsque j'ai travaillé pour la première fois avec Flask et SQLAlchemy, je n'ai pas aimé cette surcharge. J'ai repris et extrait le code de gestion des sessions de l'extension. Cette approche fonctionne, bien que j'ai découvert qu'il est assez difficile de faire cette intégration correctement.
Ainsi, l'approche la plus simple (qui est utilisée dans un autre projet sur lequel je travaille) est de laisser tomber la fonction Flask-SQLAlchemy
et n'utilise aucune des fonctions supplémentaires qu'il offre. Vous aurez le db.session
et vous pouvez l'utiliser comme si c'était pur SQLAlchemy
installation.
Flask-SQLAlchemy vous offre un certain nombre d'options intéressantes que vous finiriez par implémenter vous-même en utilisant SQLAlchemy.
Aspects positifs de l'utilisation de Flask-SQLAlchemy
- Flask_SQLAlchemy gère la configuration, l'installation et le démontage des sessions pour vous.
- Vous disposez d'un modèle de base déclaratif qui facilite l'interrogation et la pagination.
- Paramètres spécifiques au backend. Flask-SQLAlchemy analyse les librairies installées pour vérifier la prise en charge de l'Unicode et, en cas d'échec, utilise automatiquement SQLAlchemy Unicode.
- possède une méthode appelée
apply_driver_hacks
qui définit automatiquement des valeurs par défaut saines pour des choses comme la taille du pool MySQL. - Possède de belles méthodes intégrées create_all() et drop_all() pour créer et supprimer toutes les tables. Utile pour les tests et dans la ligne de commande python si vous avez fait quelque chose de stupide.
- Cela vous donne get_or_404()au lieu de get() et find_or_404() au lieu de find() Exemple de code à > http://flask-sqlalchemy.pocoo.org/2.1/queries/
Définir automatiquement les noms des tables. Flask-SQLAlchemy définit automatiquement les noms de vos tables en convertissant vos noms de tables en nombres. ClassName
> class_name
Ceci peut être remplacé par le paramètre __tablename__
classe Élément de liste
Aspects négatifs de l'utilisation de Flask-SQLAlchemy
- L'utilisation de Flask-SQLAlchemy ajoutera des difficultés supplémentaires à la migrer de Flask vers, disons, Pyramid si vous en avez un jour besoin. Ceci est principalement dû au modèle de base déclaratif personnalisé de Flask_SQLAchemy.
- En utilisant Flask-SQLAlchemy vous risquez d'utiliser un paquet avec une communauté beaucoup plus petite que SQLAlchemy lui-même, que je ne peux pas facilement abandonner le développement actif de sitôt.
- Certains extras de Flask-SQLAlchemy peuvent vous rendre confus si vous ne savez pas qu'ils sont là.
Pour être honnête, je ne vois pas d'avantages. IMHO, Flask-SQLAlchemy crée une couche supplémentaire dont vous n'avez pas vraiment besoin. Dans notre cas, nous avons une application Flask assez complexe avec de multiples bases de données/connexions (maître-esclave) utilisant à la fois ORM et Core où, entre autres choses, nous devons contrôler nos sessions / transactions DB (par exemple les modes dryrun vs commit). Flask-SQLAlchemy ajoute quelques fonctionnalités supplémentaires telles que la destruction automatique de la session en assumant certaines choses pour vous, ce qui n'est très souvent pas ce dont vous avez besoin.
La documentation de SQLAlchemy indique clairement que vous devriez utiliser Flask-SQLAlchemy (surtout si vous ne comprenez pas ses avantages !):
[...] des produits tels que Flask-SQLAlchemy [...] SQLAlchemy recommande fortement d'utiliser ces produits lorsqu'ils sont disponibles.
Cette citation et une motivation détaillée se trouvent dans la deuxième question de l'enquête. FAQ sur les sessions .
Comme le suggère @schlamar, Flask-SqlAlchemy est définitivement une bonne chose. J'aimerais juste ajouter un peu de contexte supplémentaire à la remarque faite ici.
N'ayez pas l'impression de choisir l'un plutôt que l'autre. Par exemple, disons que nous voulons récupérer tous les enregistrements d'une table à l'aide d'un modèle en utilisant Flask-Sqlalchemy. C'est aussi simple que
Model.query.all()
Pour un grand nombre de cas simples, Flask-Sqlalchemy sera parfaitement adapté. Le point supplémentaire que je voudrais faire est que, si Flask-Sqlalchemy ne va pas faire ce que vous voulez, alors il n'y a aucune raison que vous ne puissiez pas utiliser SqlAlchemy directement.
from myapp.database import db
num_foo = db.session.query(func.count(OtherModel.id)).filter(is_deleted=False).as_scalar()
db.session.query(Model.id, num_foo.label('num_foo')).order_by('num_foo').all()
Comme vous pouvez le voir, nous pouvons facilement passer de l'un à l'autre sans problème et dans le deuxième exemple, nous utilisons en fait les modèles définis par Flask-Sqlalchemy.
- Réponses précédentes
- Plus de réponses