Se connecter à une Base de données dans le Flacon, l'Approche Qui est mieux?

De la méthode: à l'Aide de g objet de http://flask.pocoo.org/docs/tutorial/dbcon/ et http://flask.pocoo.org/docs/patterns/sqlite3/

import sqlite3
from flask import g

DATABASE = '/path/to/database.db'

def connect_db():
    return sqlite3.connect(DATABASE)

@app.before_request
def before_request():
    g.db = connect_db()

@app.teardown_request
def teardown_request(exception):
    if hasattr(g, 'db'):
        g.db.close()

Deux méthode: à l'Aide de Mystérieux _app_ctx_stack de https://github.com/mitsuhiko/flask/blob/master/examples/flaskr/flaskr.py

from sqlite3 import dbapi2 as sqlite3
from flask import Flask, request, session, g, redirect, url_for, abort, \
     render_template, flash, _app_ctx_stack
def get_db():
    """Opens a new database connection if there is none yet for the
    current application context.
    """
    top = _app_ctx_stack.top
    if not hasattr(top, 'sqlite_db'):
        top.sqlite_db = sqlite3.connect(app.config['DATABASE'])
    return top.sqlite_db


@app.teardown_appcontext
def close_db_connection(exception):
    """Closes the database again at the end of the request."""
    top = _app_ctx_stack.top
    if hasattr(top, 'sqlite_db'):
        top.sqlite_db.close()

Quelle méthode est la meilleure? Quelle est la différence?

InformationsquelleAutor Gaby Solis | 2013-05-01
  1. 35

    La différence entre les deux est que la méthode crée une connexion sur g.db si vous en avez besoin ou pas, tandis que la deuxième méthode uniquement crée la connexion lorsque vous appelez get_db pour la première fois dans le contexte de l'application.

    Si vous comparez les deux, à l'aide de cette installation:

    yourapp = Flask(__name__)

# setup g.db or app_context here
# Add a logging statement (print will do)
# to the get_db or before_request functions
# that simply says "Getting the db connection ..."
# Then access /and /1

@yourapp.route("/")
def index():
    return "No database calls here!"

@yourapp.route("/<int:post_id>")
def show_post(post_id):
    # get a post using g.db or get_db
    return "Went to the DB and got {!r}".format(post)

    Vous verrez que quand vous frappez / à l'aide de la @app.before_request setup ( g.db ), vous obtenez une connexion si vous l'utilisez ou pas, tout en utilisant la _app_context route, vous obtenez seulement une connexion lorsque vous appelez get_db.

    Pour être juste, vous pouvez également ajouter un descripteur de g qui fera la même paresseux de la connexion (ou dans la vraie vie, l'acquisition d'une connexion à partir d'un pool de connexion). Et dans les deux cas, vous pouvez utiliser un peu plus de magie (werkzeug.local.LocalProxy pour être précis) pour créer votre propre personnalisé thread local qui agit comme g, current_app et request (entre autres).

    InformationsquelleAutor Sean Vieira
  2. 12

    La première est la question de l'acquisition de connexions, même quand ils ne sont pas nécessaires. Le second a l'inconvénient de jouer avec les éléments internes d'un tiers cadre, et en plus c'est assez illisible.

    Des deux à lui seul, le second est probablement le meilleur choix. Non seulement il n'est pas l'acquisition d'une connexion pour les routes qui n'en a pas besoin, il n'a pas d'acquérir la connexion si vous allez vers le bas tout chemin de code qui n'en a pas besoin, même si d'autres chemins du code de la route en nécessite un. (Par exemple, si vous avez une certaine forme de validation, vous avez seulement besoin de la connexion si la validation passe; ce n'est pas ouvrir un lors de la validation échoue.) Vous n'acquérir que des liens avant de les utiliser avec cette mise en place.

    Cependant, vous pouvez éviter de jouer avec les éléments internes et de bénéficier de tous ces avantages. Personnellement, j'ai créé mes propres méthodes globales:

    import flask
import sqlite3

def request_has_connection():
    return hasattr(flask.g, 'dbconn')

def get_request_connection():
    if not request_has_connection():
        flask.g.dbconn = sqlite3.connect(DATABASE)
        # Do something to make this connection transactional.
        # I'm not familiar enough with SQLite to know what that is.
    return flask.g.dbconn

@app.teardown_request
def close_db_connection(ex):
    if request_has_connection():
        conn = get_request_connection()
        # Rollback
        # Alternatively, you could automatically commit if ex is None
        # and rollback otherwise, but I question the wisdom 
        # of automatically committing.
        conn.close()

    Puis, tout au long de l'application, toujours obtenir votre connexion via get_request_connection, comme vous le feriez pour votre get_db fonction. Simple et d'une grande efficacité. Fondamentalement, le meilleur des deux mondes.

    Edit:

    En y repensant, je n'aime vraiment pas le fait que ce sont des méthodes globales, mais je pense que la raison pour cela est parce que c'est comment Flacon de travaux: il vous donne "globals" qui fait le point sur le thread de gens du coin.

    InformationsquelleAutor jpmc26
  3. 8

    Je recommande En Flacon De SQLAlchemy, qui s'étend de SQLAlchemy pour une utilisation dans le Flacon, donc il prend en charge plusieurs bases de données différentes. (Exemple: Flacon-SQLAlchemy documentation)

    De l'installation:

    from flask import Flask
from flask.ext.sqlalchemy import SQLAlchemy

app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:////tmp/test.db'
db = SQLAlchemy(app)


class User(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    username = db.Column(db.String(80), unique=True)
    email = db.Column(db.String(120), unique=True)

    def __init__(self, username, email):
        self.username = username
        self.email = email

    def __repr__(self):
        return '<User %r>' % self.username

    Maintenant, vous pouvez simplement importer/utilisation de la User classe d'accès de l'Utilisateur table dans votre base de données.

    Créer de nouveaux utilisateurs:

    >>> from yourapplication import User
>>> admin = User('admin', '[email protected]')
>>> guest = User('guest', '[email protected]')

    Ajoutez les utilisateurs à la base de données:

    >>> db.session.add(admin)
>>> db.session.add(guest)
>>> db.session.commit()

    De requête pour les utilisateurs déjà dans la base de données:

    >>> users = User.query.all()
[<User u'admin'>, <User u'guest'>]
>>> admin = User.query.filter_by(username='admin').first()
<User u'admin'>
    • si vous n'allez pas à afficher l'approche qui est mieux, au moins montrer comment se connecter à une base de données en Flacon
    • Cet exemple comprend tout le nécessaire pour se connecter à la base de données, puis de la requête et ajouter des utilisateurs. Je ne comprends pas ce que tu veux dire par la façon de se connecter? SQLAlchemy gère toutes les connexions derrière les coulisses.
    • Vous êtes correct. Je pense que j'étais aussi en supposant une réponse devrait montrer quand aussi déconnecter/fermer la connexion. Comment voulez-vous mettre en place une connexion/déconnexion? Method One: Using special g object OU Method Two: Using Mysterious _app_ctx_stack.
    • Excellent point; ma réponse ne répond pas directement à la question initiale de savoir laquelle des deux approches est la mieux, mais fournit une toute autre option.
    InformationsquelleAutor arboc7
  4. 4

    J'irais avec la méthode plus lisible et moins "hackish".

    La méthode 2 est probablement conçu pour flacon extensions de l'intégration (exemple et explication de l'app-ctx-pile). Même s'ils ont probablement très semblable effet, la méthode doit être utilisée pour les cas normaux.

    InformationsquelleAutor Robert Lujo