[FEATURE] FastAPISessionMaker documentation
transfluxus opened this issue · comments
Hi is there an example somewhere on how to use the SessionMaker?
Thank you!
Sorry I've been busy and haven't had time to finish the documentation, but I'll do this now!
nice, thanks for updating it.
I have questions related to your implementation. on the starlette and fastapi documentation is explains using database asycn. I guess that would look quite different here. I implemented the db_session in the middleware before I saw your response, it has the commit, so I save writing that everywhere... that's an approach that I have seen somewhere else. Optimization is so early in the project not yet priority, but while writing this.... maybe I shouldn't just blindly assume that having the commit and an eventual rollback in the middleware is a bit to generic :)
starlette and fastapi documentation is explains using database asycn
I'm not sure what you mean by this, but you can't combine async database usage with sqlalchemy orm (and therefore sqlalchemy sessions). The implementation here is specifically for use with sqlalchemy orm, and if you want to use an async database driver you can, but then you just wouldn't need a sessionmaker anyway.
The reason I don't like using a middleware for sessions is that it adds some small overhead to every request even for endpoints that don't hit the database, and adds more response latency for requests involving the database that you don't expect to fail (since it requires you to wait for the commit before you can send a response).
On top of that, the only benefit, as far as I'm aware, is that if the commit fails, you'll get a 500 error sent to the client instead of a 200. That's potentially useful for quickly identifying problems, but you can still handle (and log) the database exceptions coming from the contextmanager dependency, so it's not like this results in completely silent failures.
Also, to be clear, a commit/rollback will happen with this approach even if you don't do it manually, you just won't see a failure raised as a 500 error.
Now, I don't think it's an unreasonable choice to prefer the middleware and 500 error, but it doesn't seem like a strictly preferable approach -- for some cases this approach might be better, for others, that approach. And if you do prefer to use middleware, you could just use the middleware approach described in the FastAPI documentation.
If you think it would be useful for me to add some form of convenience wrapper for the middleware approach in this package, let me know and we could add that too.
On top of that, if you are actually potentially expecting errors on the commit, it's probably better to handle it directly in your endpoint code so you can give a descriptive response about what went wrong. So you wouldn't save the effort of writing the commit anyway.
Thanks for the explanation. I am hitting the the last point you are giving more and more and I agree that it make much more sense to handle the error exactly where it happens, ... in the endpoint method.
I will try to use the sessionMaker of your package
@transfluxus Glad to help.
And please continue to report any issues you run into, whether questions, or especially if you notice any performance issues or bugs!