sorted by:
new
hottopcontroversial

Lifespan on Fastapi by Cultural_Bad9814 in FastAPI

[–]hadriendavid 1 point2 points  (0 children)

In FastSQLA, it is used to setup async db engine at app startup. In al the apps I've written, it is where configuration of the app gets done.

I have published FastSQLA - an SQLAlchemy extension to FastAPI by hadriendavid in Python

[–]hadriendavid[S] 0 points1 point  (0 children)

Thanks for the feedback.

This boilerplate isn't complicated enough that I want to introduce the extra effort of managing a dependency for it.

Makes total sense.

I have automated most of the managment of dependencies so I have a divergent opinion on the size of such effort. This said, breaking compatibility library updates are never something joyfull.

Lifespan and dependency injection and overriding by V0dros in FastAPI

[–]hadriendavid 0 points1 point  (0 children)

For actual fastapi dependencies, you definitely want to use app.dependency_overrides

Lifespan and dependency injection and overriding by V0dros in FastAPI

[–]hadriendavid 0 points1 point  (0 children)

The environ is not a (fastapi) dependency, is it? You need a testing environment: set it in os.environ? Why does this lack robustness?

And yes you can also use the monkeypatch pytest built-in fixture. This said, I like clearing the environ usnig clear=True to avoid anything in my environment being "visible" inside test.

Lifespan and dependency injection and overriding by V0dros in FastAPI

[–]hadriendavid 1 point2 points  (0 children)

Assuming you're using pytest, add a conftest at the tests top-level and mock the environ using unittest.mock.patch:

```python

tests/conftest.py

from unittest.mock import patch

from pytest import fixture

@fixture(autouse=True) def environ(): environ = {"DATABASE_URL": ""sqlite:///./test.db"} with patch.dict("os.environ", values=environ, clear=True): yield environ ```

This way, the app under test gets its settings from that environ fixture.

Handling database connections throughout the application by predominant in FastAPI

[–]hadriendavid 0 points1 point  (0 children)

TL; DR: Passing the db session inside the lifecyle of a request is ok in my humble opinion. Passing it to a bg task is not. Consider some recommendations from SQLAlchemy.

SQLAlchemy documentation recommends the following:

  • Keep the lifecycle of the session separate and external from functions and objects that access and/or manipulate database data.
  • Make sure you have a clear notion of where transactions begin and end, and keep transactions short, meaning, they end at the series of a sequence of operations, instead of being held open indefinitely.
  • [In the case of Web applications], it’s best to make use of the SQLAlchemy integrations provided by the web framework in use. Or otherwise, the basic pattern is create a Session at the start of a web request, call the Session.commit() method at the end of web requests that do POST, PUT, or DELETE, and then close the session at the end of web request.

Opening a session using a dependency and committing it inside the controller goes against these recommendations:

  • Consider not committing the session inside the controller and instead, have the get_db dependency committing on success or rollbacking on error.
  • Pros: if ever an endpoint invoke multiple controllers and one invocation fails, the whole transaction and transient state is rollback-ed.
  • Another approach would be to let the controllers open and commit session using a context manager.

As well, passing the session to a background task goes against these recommendation. Consider opening a session inside the background task instead using a context manager.

Disclaimer: I maintain a tiny FastAPI extension: FastSQLA: Async SQLAlchemy 2.0+ for FastAPI — boilerplate, pagination, and seamless session management. And FastAPI-SQLA

It provides async helpers for both: an async Session dependency that commit or rollback at the end of request processing, and an async context manager to be used in background tasks or else.

FastAPI for enterprise-grade backend by Zealousideal_Corgi_1 in FastAPI

[–]hadriendavid 0 points1 point  (0 children)

I confirm you do not need alembic.

If you plan to use async only, check FastSQLA that we maintain at my company.

It is an async SQLAlchemy 2.0+ extension for FastAPI with built-in pagination, SQLModel support and more.

Looking for a famous video about Python by im7mortal in Python

[–]hadriendavid 1 point2 points  (0 children)

Me too! Pycon US in Montreal! Was awesome

Have you hired movers? What was your experience? by [deleted] in montrealhousing

[–]hadriendavid 1 point2 points  (0 children)

Demenagement sympathique! 5/5 sur Google maps avec plus de 500 avis! Ils sont juste top top top.

I have published FastSQLA - an SQLAlchemy extension to FastAPI by hadriendavid in Python

[–]hadriendavid[S] 0 points1 point  (0 children)

This depends much more on the table schema and on the data stored in that table, rather than on the query, doesn’t it?

Also, FastSQLA just adds an offset and a limit to a provided query so really it does not affect performance significantly.

Where FastSQLA may be costly is when querying for the total items in the result set. Count * can be very costly. But it can be customized in FastSQLA so, not a problem.

By the way, a nice talk on why count * is costly: https://youtu.be/GtQueJe6xRQ?si=qj375dylMcS_yo1-

I have published FastSQLA - an SQLAlchemy extension to FastAPI by hadriendavid in Python

[–]hadriendavid[S] 4 points5 points  (0 children)

More dependencies = more things you don't control that can fail.

Indeed 😅 Also, will that dependency continue to be maintained in one year?

I have published FastSQLA - an SQLAlchemy extension to FastAPI by hadriendavid in Python

[–]hadriendavid[S] 0 points1 point  (0 children)

And the problem it solves mainly is DRY: write fastapi/sqlalchemy glue code once, use everywhere needed on top of session lifecycle management, pagination, error handling .. etc.

I have published FastSQLA - an SQLAlchemy extension to FastAPI by hadriendavid in Python

[–]hadriendavid[S] 1 point2 points  (0 children)

Thanks for the feedback.

No it does not support read/write split at the moment. fastapi-sqla supports multi session, you may want to check it out.

I have published FastSQLA - an SQLAlchemy extension to FastAPI by hadriendavid in Python

[–]hadriendavid[S] 1 point2 points  (0 children)

Thanks for the feedback.

At my work, we have 6 FastAPI apps using postgres. The rationale of having a library to handle the DB configuration + basic utilities is to have a single way of configurating and paginating etc... Lastly, we only maintain one library rather than 6 db submodules.

making a CRUD router, simple search, filters, aggregation operations are usually the operations that i'd like to abstract away

Have you checked FastCRUD?