Does graphene_sqlalchemy keep sessions open?

tl;dr

Does graphene_sqlalchemy keep sessions open? I’m having the problem that Postgres doesnt run drop_all() in my test suite.

Explanation

Hi, I have a fastAPI app and I’m using graphene_sqlalchemy to generate an API from database models defined on the declarative base of SQLAlchemy. The database is postgres. For testing I am running some pytests against the API while it’s running. So, I start a throw-away postgres container, then I start the API app, then I run pytest.

The tests include a reset_testdata() function which also uses the SQLAlchemy ORM. It looks like:

def reset_testdata():
    close_all_sessions()  # from sqlalchemy.orm.session
    models.Base.metadata.drop_all(bind=engine)
    models.Base.metadata.create_all(bind=engine)

    db.add_all([
        # ... add stuff
    ])

    db.commit()
    db.close()

I noticed, that once reset_testdata() is used, the pytest process hangs. No errors, not able to Ctrl+C, it just waits. I had this issue before and it usually stems from Postgres not allowing stuff like drop_all() if there are still active sessions. After some trying out I found that queries from my app (which are implemented by graphene_sqlalchemy) seem to keep a session open. (I used this example in my app: https://docs.graphene-python.org/projects/sqlalchemy/en/latest/tutorial/#defining-our-models)

I tested this, and basically I can circumvent this problem by adding a middleware that closes all sessions after every request.

@app.middleware('http')
async def close_sessions(request: Request, call_next):
    try:
        response = await call_next(request)
    finally:
        close_all_sessions()
    return response

I wonder whether I am missing something here? Any experience with this issue (if it is even an issue)?

[davidroeca]

Unfortunately, that renders a lot of graphene-sqlalchemy’s relationship and queries capabilities useless. My preferred approach is closer to this one within a similar thread.

Along the lines of:

from contextvars import ContextVar
import uuid

_request_id_ctx_var = ContextVar('request_id', default=None)
def get_request_id():
    return _request_id_ctx_var.get()

engine = create_engine(SQLALCHEMY_DATABASE_URL)
session = scoped_session(
    sessionmaker(autocommit=False, autoflush=False, bind=engine),
    scopefunc=get_request_id,
)
# ... create Base, as in the example
Base.query = session.query_property()


@api.middleware("http")
async def set_request_id(request, call_next):
    request_id = str(uuid.uuid4())
    ctx_token = _request_id_ctx_var.set(request_id)

    response = await call_next(request)

    _request_id_ctx_var.reset(ctx_token)
    return response

[davidroeca]

@dmitrybabanovforreal did you read this doc (in particular, this section)?

I don’t think avoiding scoped_session is necessarily a “best practice” but rather a recommendation from tiangolo to reduce confusion for new users. In this case, avoiding scoped_session requires you to write resolver functions for every relationship. Using scoped_session in the way SQLAlchemy recommends (one session per request) will enable you to use graphene-sqlalchemy with its original design while not having to write custom code if you don’t have to.

Now, if you’re stuck writing your own resolvers anyway (due to additional custom logic, or something else), then your approach is still a fine solution. The more models/relationships, the more painful it gets though.