Sorry for taking so long to reply. I'm afraid I don't check
this mailing
list as often as I should. :)
Totally fine, thanks for the reply!
When I thought about that use case, I supposed it would be OK to
instantiate the app and start the app context from within the script,
as it
would also give you access to Flask's config file. But I did not think
about multithreading. Would you recommend against creating the app instance
and the app context in a command-line script?
Well, that was what I tried to do first, but, as I said, everything broke
down when I tried to do multithreading (and got worse when I tried to setup
multiprocessing). The problem is that Flask-SQLAlchemy tries to manage the
DB session for you, and, since SQLAlchemy sessions aren't thread-safe, my
command-line script kept crashing, and a few hours of poking around
couldn't fix it. If I'd been willing to poke around more in
Flask-SQLAlchemy's, I might have figured something out, but it just didn't
seem to be worth the effort, when manually managing my sessions fixed the
problem completely.
Yeah, maybe something like scoped_session()[1] could have help, but no
point in rewriting history (unless there's a mistake in your git reflog ;-)
)
Indeed your integration layer seems slim enough. Thanks!
[1]
https://docs.sqlalchemy.org/en/14/orm/contextual.html
While most of our flask apps have command-line scripts, I don't think many
of them go full multithreading or multiprocessing, with the notable
exception of Fedora-Messaging listeners, since the callback is run in a
thread. I may end up publishing the sqlalchemy integration layer that I
have written so we can use it in our apps without re-inventing a slightly
different wheel every time. It's one more project to keep track of, but it
should reduce the overall amount of code we maintain and tech debt we have
to deal with.
Thoughts?
Name ideas before I pick some french word nobody can pronounce?
Aurélien