flask-sqlalchemy icon indicating copy to clipboard operation
flask-sqlalchemy copied to clipboard

Revisit SQLALchemy engine cache logic

Open rsyring opened this issue 6 years ago • 0 comments

We currently cache the SQLAlchemy engine in _EngineConnector based on the echo setting. Prior to #684, that was the main engine option we supported. However, with more ways to customize the engine options, do we need to cache the engine differently? What kind of assumptions are we making and what kind of scenarios do we want to support with respect to caching the engine object?

Some considerations:

  • If I understand SQLAlchemy.get_engine() correctly, we are already using state to cache the _EngineConnector instance per application. Since the engine is cached on that instance, we are caching the engine connection per application.
  • _EngineConnector will currently return the existing engine as long as the database URI/binds are the same and the echo setting is the same. So, it seems the goal is to support changing db connections or echo configuration settings after an engine is established and FSA will detect this and create a new engine accordingly.
  • Enhancing this logic to consider all engine options is possible, but it seems like that code path was specifically part of what would get cached. I'm not sure if there are performance issues that could arise if you were calling get_options() every time you wanted to get an engine.

As a result of these considerations, I believe it's best to leave the current caching logic as-is for #684 and revisit this issue if/when other users can provide scenarios where the current behavior is [un]desired.

rsyring avatar Mar 14 '19 18:03 rsyring