Quand Flask.g devrait-il être utilisé?

Question

J'ai vu que g passera du contexte de la demande au contexte de l'application dans Flask 0.10, ce qui m'a rendu confus quant à l'utilisation prévue de g.

Ma compréhension (pour Flask 0.9) est que :

• g vit dans le contexte de la demande, c'est-à-dire qu'il est créé à chaque démarrage de la demande et est disponible jusqu'à sa fin
• g est destiné à être utilisé comme un "tableau noir de la demande", où je peux mettre des choses pertinentes pour la durée de la demande (c'est-à-dire définir un indicateur au début de la demande et le gérer à la fin, éventuellement à partir d'une paire before_request/after_request)
• en plus de contenir l'état au niveau de la demande, g peut et doit être utilisé pour la gestion des ressources, c'est-à-dire tenir des connexions de base de données, etc.

Lesquelles de ces phrases ne sont plus vraies dans Flask 0.10 ? Quelqu'un peut-il me diriger vers une ressource discutant des raisons du changement ? Que devrais-je utiliser comme "tableau noir de la demande" dans Flask 0.10 - devrais-je créer mon propre proxy spécifique à l'application/extension et le pousser à la pile de contexte before_request ? Quel est l'intérêt de la gestion des ressources au niveau de l'application, si mon application vit longtemps (pas comme une demande) et donc les ressources ne sont jamais libérées ?

Answer 1

Modèles Flask avancés, comme mentionné par Markus, explique certains des changements apportés à g dans la version 0.10 :

• g vit désormais dans le contexte de l'application.
• Chaque requête crée un nouveau contexte d'application, effaçant l'ancien, donc g peut toujours être utilisé pour définir des drapeaux par requête sans modification du code.
• Le contexte de l'application est retiré après l'appel de teardown_request. (La présentation d'Armin explique que des tâches comme la création de connexions à la base de données sont des actions qui préparent l'environnement de la requête, et ne doivent pas être gérées à l'intérieur de before_request et after_request)

Answer 2

En complément des informations de ce fil : j'ai été un peu confus par le comportement de flask.g également, mais quelques tests rapides m'ont aidé à le clarifier. Voici ce que j'ai essayé :

from flask import Flask, g
app = Flask(__name__)

with app.app_context():
    print('dans le contexte de l'application, avant le premier contexte de requête')
    print('définition de g.foo à abc')
    g.foo = 'abc'
    print('g.foo devrait être abc, est : {0}'.format(g.foo))

    with app.test_request_context():
        print('dans le premier contexte de requête')
        print('g.foo devrait être abc, est : {0}'.format(g.foo))
        print('définition de g.foo à xyz')
        g.foo = 'xyz'
        print('g.foo devrait être xyz, est : {0}'.format(g.foo))

    print('dans le contexte de l'application, après le premier contexte de requête')
    print('g.foo devrait être abc, est : {0}'.format(g.foo))

    with app.test_request_context():
        print('dans le second contexte de requête')
        print('g.foo devrait être abc, est : {0}'.format(g.foo))
        print('définition de g.foo à pqr')
        g.foo = 'pqr'
        print('g.foo devrait être pqr, est : {0}'.format(g.foo))

    print('dans le contexte de l'application, après le second contexte de requête')
    print('g.foo devrait être abc, est : {0}'.format(g.foo))

Et voici le résultat obtenu :

dans le contexte de l'application, avant le premier contexte de requête
définition de g.foo à abc
g.foo devrait être abc, est : abc  

dans le premier contexte de requête
g.foo devrait être abc, est : abc
définition de g.foo à xyz
g.foo devrait être xyz, est : xyz  

dans le contexte de l'application, après le premier contexte de requête
g.foo devrait être abc, est : xyz  

dans le second contexte de requête
g.foo devrait être abc, est : xyz
définition de g.foo à pqr
g.foo devrait être pqr, est : pqr  

dans le contexte de l'application, après le second contexte de requête
g.foo devrait être abc, est : pqr

Comme l'a dit Y4Kman ci-dessus, "Chaque requête pousse un nouveau contexte d'application". Et comme le disent les docs de Flask, le contexte d'application "ne sera pas partagé entre les requêtes". Maintenant, ce qui n'a pas été explicitement dit (bien que je suppose que cela découle de ces déclarations), et ce que mes tests montrent clairement, c'est que vous ne devriez jamais créer explicitement plusieurs contextes de requête imbriqués dans un contexte d'application, car flask.g (et compagnie) n'a pas de magie permettant de fonctionner dans les deux "niveaux" de contexte, avec des états différents existant indépendamment aux niveaux de l'application et de la requête.

La réalité est que le "contexte de l'application" est potentiellement un nom assez trompeur, car app.app_context() est un contexte par requête, exactement le même que le "contexte de requête". Pensez-y comme un "contexte de requête allégé", uniquement nécessaire dans le cas où vous avez besoin de certaines des variables qui nécessitent normalement un contexte de requête, mais vous n'avez pas besoin d'accéder à un objet de requête (par exemple, lors de l'exécution d'opérations de base de données en lot dans un script shell). Si vous essayez d'étendre le contexte de l'application pour englober plus d'un contexte de requête, vous cherchez des ennuis. Donc, plutôt que mon test ci-dessus, vous devriez plutôt écrire du code comme ceci avec les contextes de Flask :

from flask import Flask, g
app = Flask(__name__)

with app.app_context():
    print('dans le contexte de l'application, avant le premier contexte de requête')
    print('définition de g.foo à abc')
    g.foo = 'abc'
    print('g.foo devrait être abc, est : {0}'.format(g.foo))

with app.test_request_context():
    print('dans le premier contexte de requête')
    print('g.foo devrait être None, est : {0}'.format(g.get('foo')))
    print('définition de g.foo à xyz')
    g.foo = 'xyz'
    print('g.foo devrait être xyz, est : {0}'.format(g.foo))

with app.test_request_context():
    print('dans le second contexte de requête')
    print('g.foo devrait être None, est : {0}'.format(g.get('foo')))
    print('définition de g.foo à pqr')
    g.foo = 'pqr'
    print('g.foo devrait être pqr, est : {0}'.format(g.foo))

Ce qui donnera les résultats attendus :

dans le contexte de l'application, avant le premier contexte de requête
définition de g.foo à abc
g.foo devrait être abc, est : abc  

dans le premier contexte de requête
g.foo devrait être None, est : None
définition de g.foo à xyz
g.foo devrait être xyz, est : xyz  

dans le second contexte de requête
g.foo devrait être None, est : None
définition de g.foo à pqr
g.foo devrait être pqr, est : pqr