SQLAlchemy: Création de vs la Réutilisation d'une Session

Juste une petite question: SQLAlchemy parle appel sessionmaker() une fois, mais l'appel de la résultante Session() classe à chaque fois que vous avez besoin de parler à votre base de données. Pour moi, cela signifie la seconde, je ferais de mon premier session.add(x) ou quelque chose de similaire, je voudrais tout d'abord faire

from project import Session
session = Session()

Ce que j'ai fait jusqu'à maintenant a été de faire l'appel session = Session() dans mon modèle une fois et puis toujours à l'importation de la même session, n'importe où dans mon application. Puisque c'est une web-applications ce serait généralement dire la même (un point de vue est exécutée).

Mais où est la différence? Quel est l'inconvénient de l'utilisation d'une séance tous les temps contre de l'utiliser pour ma base de données des trucs jusqu'à ce que ma fonction est effectuée, puis en créer un nouveau la prochaine fois que je veux parler à mon DB?

- Je obtenir que si j'utilise plusieurs threads, chacun doit obtenir leur propre session. Mais à l'aide de scoped_session(), je l'ai déjà assurez-vous que le problème n'existe pas, puis-je?

Veuillez préciser si l'une de mes hypothèses sont fausses.

InformationsquelleAutor javex | 2012-08-31
  1. 192

    sessionmaker() est une usine, il est là pour les encourager à placer des options de configuration pour la création de nouveaux Session objets dans un seul endroit. Il est facultatif, en ce que vous pourrait tout aussi bien appeler Session(bind=engine, expire_on_commit=False) à tout moment vous avez besoin d'un nouveau Session, sauf que son détaillé et redondants, et j'ai voulu arrêter la prolifération de la petite échelle "aides" que chacun a abordé la question de cette redondance dans certains de nouvelles et plus de confusion.

    Donc sessionmaker() est juste un outil pour vous aider à créer Session objets lorsque vous en avez besoin.

    Prochaine partie. Je pense que la question est, quelle est la différence entre faire un nouveau Session() à différents points plutôt qu'à l'aide d'un tout le chemin à travers. La réponse, pas très bien. Session est un conteneur pour tous les objets que vous avez mis en elle, et puis elle conserve également la trace d'une transaction ouverte. Au moment de l'appel rollback() ou commit(), la transaction est terminée, et le Session a pas de connexion à la base de données jusqu'à ce qu'il est appelé à émettre SQL de nouveau. Les liens qu'elle détient à votre mappé objets sont faibles référencement, à condition que les objets soient propres des changements à venir, de sorte que même à cet égard, la Session se vide de lui-même de retour pour une nouvelle marque de l'état lors de votre demande perd toutes les références à des objets mappés. Si vous le laisser à sa valeur par défaut "expire_on_commit" réglage, puis tous les objets sont expirés après un commit. Si Session se bloque autour de cinq ou vingt minutes, et toutes sortes de choses ont changé dans la base de données la prochaine fois que vous l'utilisez, il va charger le tout de la marque nouvel état la prochaine fois que vous accéder à ces objets, même si ils ont été assis dans la mémoire pour une vingtaine de minutes.

    Dans les applications web, nous avons l'habitude de dire, hey, pourquoi ne pas vous faire une nouvelle marque Session sur chaque demande, plutôt que d'utiliser le même maintes et maintes fois. Cette pratique assure que la nouvelle demande commence "propre". Si certains objets de la demande précédente, n'ont pas été nettoyée encore, et si vous avez peut-être désactivé "expire_on_commit", peut-être certains de l'état de la demande précédente est toujours traîner, et que l'état pourrait même être assez vieux. Si vous êtes prudent de laisser expire_on_commit allumé et certainement appel commit() ou rollback() à la demande de la fin, alors c'est bien beau, mais si vous commencez avec une nouvelle marque Session, alors il n'est même pas une question que vous êtes commencer le nettoyage. Donc, l'idée de départ de chaque demande avec un nouveau Session est vraiment juste de la façon la plus simple de s'assurer que vous êtes de départ frais, et faire de l'utilisation de expire_on_commit assez bien option, que ce drapeau peut encourir beaucoup de SQL pour une opération qui appelle commit() au moyen d'une série d'opérations. Ne sais pas si cela répond à votre question.

    De la prochaine ronde, ce que vous mentionnez sur le filetage. Si votre application est multithread, nous vous recommandons de faire assurer la Session dans l'utilisation de locaux à...quelque chose. scoped_session() par défaut rend local pour le thread courant. Dans une application web, du local à la demande est en fait encore mieux. En flacon de SQLAlchemy envoie une coutume "fonction oscilloscope" à scoped_session() de sorte que vous obtenez une demande d'étendue de session. La moyenne de la Pyramide de l'application des bâtons de la Séance, dans la "demande" du registre. Lors de l'utilisation de programmes comme ceux-ci, le "créer une nouvelle Session sur le début de la demande de" l'idée continue à ressembler à la façon la plus simple de garder les choses en ordre.

    • Wow, ce qui répond à toutes mes questions sur la SQLAlchemy partie et ajoute même quelques infos à propos de Flacon et de la Pyramide! Bonus: les développeurs de réponse 😉 je souhaite que je pourrais voter plus d'une fois. Merci beaucoup!
    • Une précision, si possible: vous dites expire_on_commit "peuvent entraîner beaucoup de SQL"... pouvez-vous donner plus de détails? J'ai pensé expire_on_commit uniquement préoccupé de ce qui se passe dans la RAM, pas ce qui se passe dans la base de données.
    • expire_on_commit peut en résulter davantage de SQL si vous ré-utiliser le même Session de nouveau, et certains objets sont toujours traîner dans cette Session, lorsque vous accédez à eux, vous obtiendrez une seule ligne, SÉLECTIONNEZ pour chacun d'eux, comme ils individuellement chaque actualisation de leur état, dans les termes de la nouvelle transaction.
    • Salut, @zzzeek. Merci pour l'excellente réponse. Je suis très nouveau en python et plusieurs choses, j'ai envie de préciser: 1) Dois-je comprendre corriger quand je crée une nouvelle "session" par l'appel de Session() la méthode qu'il va créer des Transactions SQL, alors la transaction sera ouvert jusqu'à ce que je commit/rollback session? 2) session() utiliser une sorte de pool de connexion ou font de la nouvelle connexion à sql à chaque fois?
    InformationsquelleAutor zzzeek
  2. 21

    En plus de l'excellente zzzeek réponse, voici une recette simple pour créer rapidement du jetable, de l'auto-joint sessions:

    from contextlib import contextmanager

from sqlalchemy import create_engine
from sqlalchemy.orm import scoped_session, sessionmaker

@contextmanager
def db_session(db_url):
    """ Creates a context with an open SQLAlchemy session.
    """
    engine = create_engine(db_url, convert_unicode=True)
    connection = engine.connect()
    db_session = scoped_session(sessionmaker(autocommit=False, autoflush=True, bind=engine))
    yield db_session
    db_session.close()
    connection.close()

    Utilisation:

    from mymodels import Foo

with db_session("sqlite://") as db:
    foos = db.query(Foo).all()
    • Est-il une raison pourquoi vous créer non pas une nouvelle session, mais une nouvelle connexion trop?
    • Pas vraiment, c'est un petit exemple pour montrer le mécanisme, bien qu'il ait un sens pour créer tout frais dans les essais, où j'utilise cette approche le plus. Il devrait être facile de développer cette fonction avec la connexion en tant qu'argument optionnel.
    InformationsquelleAutor Berislav Lopac
  3. -3

    Vous pouvez créer une session à l'aide de la db

    db = SQLAlchemy(app)
engine = db.engine
Session = sessionmaker(engine)
session = Session()
    • Je voudrais savoir d'où ou de qui a dit que c'était un spécifique Flacon question?? C'est certainement pas spécifique à la Gourde - le titre en question ou les questions les balises ne sont pas de l'état flacon n'importe où! à côté de sqlalchemy n'est pas juste pour le flacon, c'est uniquement parce que quelqu'un l'a créée quelques simples liaisons esier à utiliser dans la fiole jaugée-sqlalchemy!
    InformationsquelleAutor mcolak