-
-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Closed
Labels
Description
First check
- I added a very descriptive title to this issue.
- I used the GitHub search to find a similar issue and didn't find it.
- I searched the FastAPI documentation, with the integrated search.
- I already searched in Google "How to X in FastAPI" and didn't find any information.
- I already read and followed all the tutorial in the docs and didn't find an answer.
- I already checked if it is not related to FastAPI but to Pydantic.
- I already checked if it is not related to FastAPI but to Swagger UI.
- I already checked if it is not related to FastAPI but to ReDoc.
- After submitting this, I commit to one of:
- Read open issues with questions until I find 2 issues where I can help someone and add a comment to help there.
- I already hit the "watch" button in this repository to receive notifications and I commit to help at least 2 people that ask questions in the future.
- Implement a Pull Request for a confirmed bug.
According to FastAPI's SQLAlchemy tutorial, db.refresh()
is called after db.commit()
. However from SQLAlchemy's documentation:
Finally, all objects within the Session are expired as the transaction is closed out. This is so that when the instances are next accessed, either through attribute access or by them being present in the result of a SELECT, they receive the most recent state. This behavior may be controlled by the Session.expire_on_commit flag, which may be set to False when this behavior is undesirable.
So in this case, db.refresh()
shouldn't be necessary as expire_on_commit
defaults to True
and the tutorial doesn't set this to False
? Or does FastAPI/Pydantic do something to the ORM object that necessitates this?