Mi pregunta es sobre el enfoque recomendado para manejar las conexiones de la base de datos cuando se usa Flask en un entorno de producción u otro entorno donde el rendimiento es una preocupación. En Flask, el objeto g está disponible para almacenar cosas, y las conexiones de bases de datos abiertas se pueden colocar allí para permitir que la aplicación las reutilice en consultas de bases de datos posteriores durante la misma solicitud. Sin embargo, el objeto g no persiste entre las solicitudes, por lo que parece que cada nueva solicitud requeriría una nueva conexión a la base de datos (y el impacto en el rendimiento que eso implica).
La pregunta más relacionada que encontré sobre este asunto es esta: cómo preservar la conexión de la base de datos en un servidor web de python, pero las respuestas solo plantean la idea abstracta de la agrupación de conexiones (sin vincularla a cómo se podría usar dentro de Flask y cómo lo haría). sobrevivir a través de solicitudes) o proponer una solución que solo es relevante para un tipo particular de base de datos o pila particular.
Entonces, mi pregunta es sobre el enfoque general que se debe tomar al producir aplicaciones creadas en Flask que se conectan a cualquier tipo de base de datos. Parece que algo relacionado con la agrupación de conexiones va en la dirección correcta, especialmente porque eso funcionaría para una aplicación tradicional de Python. Pero me pregunto cuál es el enfoque recomendado cuando se usa Flask debido a los problemas de persistencia antes mencionados en las conexiones, y también al hecho de que las aplicaciones de Flask en producción se ejecutan desde servidores WSGI, lo que potencialmente agrega más complicaciones.
EDITAR: Basado en los comentarios que recomiendan matraz sqlalchemy. Suponiendo que Flask Sqlalchemy resuelva el problema, ¿funciona también para Neo4J o, de hecho, para cualquier base de datos arbitraria que utilice la aplicación Flask? Muchos de los conectores de bases de datos existentes ya admiten la agrupación de forma nativa, entonces, ¿por qué introducir una dependencia adicional cuyo objetivo principal es proporcionar capacidades de ORM en lugar de la administración de conexiones? Además, ¿cómo sortea sqlalchemy el problema fundamental de la persistencia en las solicitudes?
Resulta que hay una forma sencilla de lograr lo que estaba buscando. Pero como sugirieron los comentaristas, si es posible seguir la ruta de la sqlalchemy del matraz, entonces es posible que desee ir por ese camino. Mi enfoque para resolver el problema es guardar el objeto de conexión en una variable de nivel de módulo que luego se importa según sea necesario. De esa manera, estará disponible para su uso desde Flask y por otros módulos. Aquí hay una versión simplificada de lo que hice:
app.py
from flask import Flask from extensions import neo4j app = Flask(__name__) neo4j.init_app(app)extensiones.py
from neo4j_db import Neo4j neo4j = Neo4j()neo4j_db.py
from neo4j import GraphDatabase class Neo4j: def __init__(self): self.app = None self.driver = None def init_app(self, app): self.app = app self.connect() def connect(self): self.driver = GraphDatabase.driver('bolt://xxx') return self.driver def get_db(self): if not self.driver: return self.connect() return self.driverejemplo.py
from extensions import neo4j driver = neo4j.get_db()Y desde aquí, el controlador contendrá el controlador de la base de datos que persistirá en las solicitudes de Flask.
Espero que ayude a cualquiera que tenga el mismo problema.