masteras it completes?
req.contextbut that's a little conceptually weird (database access has nothing to do with a request). Particularly given that I'm working with an ASGI instance at the moment, I'm not sure what else would be safe, though
req.contextwould be a reasonable choice. In a way, the session is associated with a given request, but I can understand that not everyone might see it that way. Alternatively you could use thread-local storage I suppose, but that arguably makes session lifetimes a tiny bit harder to reason about. There is also another school of thought that recommends not using a per-request session at all, but simply setting up and committing your transactions as locally as possible to the associated business logic. It can be a bit more tedious but also may make it easier to track down errors if/when they occur. I know @jmvrbanac is a fan of this last approach and may have some thoughts.
scoped_sessionshould do everything you need. Storing it on the context is reasonable, but you can also make the session a global and use it from there by importing it. The docs use the example of a web request as the basis for the scoped session.
awaiting, the thread goes to work on a second request for the same device that results in another IOT message. If one of the IOT communications times out but the other completes, I can imagine pending changes to the device SQLAlchemy object getting flushed to the database from a non-related request if they are not committed prior to contacting the IOT device in the other request. That would be a very difficult bug to identify and fix, and one that wouldn't get caught by automated testing)
req.contextvia middleware for the moment. It's a little weird (since the database session isn't coming in with the request), but
req.context.sessionisn't that much worse than
self.sessionor similar in practice
@ianbeck Re the stuff I've seen -- at least this seems to be legit https://github.com/encode/databases . From the same authors as Starlette etc. But that gives roughly the equivalent of SQLAlchemy Core, so probably it's the same thing you mentioned
barring things like GINO that use SQLAlchemy Core and eschew the ORM
GINO - GINO Is Not ORM