如何使用 SQLAlchemy 在 Flask 应用程序中初始化 Postgresql 数据库

Question

TheFlask tutorial (and many other tutorials out there ) suggests that the engine , the db_session and the Base (an instance of declarative_metadata ) are all created at import-time.

This creates some problems, one being, that the URI of the DB is hardcoded in the code and evaluated only once. One solution is to wrap these calls in functions that accept the app as a parameter, which is what I've done. Mind you - each call caches the result in app.config :

def get_engine(app):                                                                           
    """Return the engine connected to the database URI in the config file.
    Store it in the config for later use.
    """
    engine = app.config.setdefault(
        'DB_ENGINE', create_engine(app.config['DATABASE_URI'](), echo=True))
    return engine                                                                              
                                                                                               
def get_session(app):                                                                          
    """Return the DB session for the database in use
    Store it in the config for later use.
    """                          
    engine = get_engine(app)
    db_session = app.config.setdefault(
        'DB_SESSION', scoped_session(sessionmaker(
            autocommit=False, autoflush=False, bind=engine)))
    return db_session
                                                                                               
def get_base(app):                     
    """Return the declarative base to use in DB models.
    Store it in the config for later use.
    """                                                                                        
    Base = app.config.setdefault('DB_BASE', declarative_base())
    Base.query = get_session(app).query_property()
    return Base                                

In init_db , I call all those functions, but there's still code smell:

def init_db(app):
    """Initialise the database"""
    create_db(app)
    engine = get_engine(app)
    db_session = get_session(app)
    base = get_base(app)

    if not app.config['TESTING']:
        import flaskr.models
    else:
        if 'flaskr.models' not in sys.modules:
            import flaskr.models
        else:
            import flaskr.models
            importlib.reload(flaskr.models)

    base.metadata.create_all(bind=engine)

The smell is of course the hoops I have to go through to import and create all models. The reason for the code above is that, when unit testing, init_db is called once for each test (in setup() , as suggested in the same tutorial ), but the import will only be performed the first time, and create_all will therefore work only that time.

Not only that, now with a session shared for the duration of the app, I have problems in parametrized negative unit tests (that is, parametrized unit tests that expect some sort of failures): the first instance of the test will trigger a failure (eg login failure, see test_login_validate_input in the tutorial ) and exit correctly, while all subsequent will bail out early because the db_session should be rolled back first. Clearly there's something wrong with the DB initialization.

What is the Right Way(TM) to initialize the database?

Answer 1

I have eventually decided to refactor the app so that it uses Flask-SQLAlchemy .

In short, the app now does something like this:

from flask_sqlalchemy import SQLAlchemy

db = SQLAlchemy()

def create_app():
    app = Flask(__name__)
    db.init_app(app)
    # ...

With the benefit of hindsight, it's definitely a cleaner approach. What put me off at the start was this entry from the tutorial (bold is mine):

Because SQLAlchemy is a common database abstraction layer and object relational mapper that requires a little bit of configuration effort, there is a Flask extension that handles that for you. This is recommended if you want to get started quickly .

Which I somehow read as "Using the Flask-SQLAlchemy extension will allow you to cut some corners, which you'll probably end up paying for later".

It's very early stages, but so far no price to pay in terms of flexibility for using said extension.