andredias / perfect_python_project Goto Github PK

From time to time, it is desirable to squash the migrations to keep them short. This article proposes an interesting approach.

According to 0.8.0 release notes:

This release improves isolation of connections and transactions across concurrent tasks:

• Database connections are now task-local and are not inherited by child tasks
• The @db.transaction decorator uses the calling task's connection
• Each new task uses a new connection unless a connection is explicitly provided

These changes improve the consistency of behavior and fix bugs where connections and transactions were not properly isolated such as: encode/databases#123, encode/databases#125, encode/databases#134, encode/databases#155, encode/databases#424, and encode/databases#452.

In most cases, these changes should not be breaking. However, if using an open transaction across tasks, the active connection (db.connection()) now needs to be explicitly passed to each task. See the new documentation for an example.

Those changes break the app fixture which wraps the app with a db.transaction(force_rollback=True): to roll back all changes made during testing.

Pydantic adopted Ruff as its linter. Let's try it here too.

Since pyproject.toml does not record any version restrictions, we need poetry.lock to define the currently used versions. Otherwise, we cannot guarantee that a newly created template instance will run. For example, fastapi-complete doesn't work with databases 0.8.0 yet but this version will be used during the template instantiation anyway because of the lack of a restriction in pyproject.toml or in poetry.lock.

I prefer to keep pyproject.toml the way it is, so it will be possible to run poetry update to update all dependencies to their latest versions anytime.

I see the following error. What can be the reason?

Improve FastAPI (minimum and complete) projects to log uncaught errors.

Other ideas that can be used are well presented at FastAPI Server Errors And Logs — Take Back Control