Using Flask-SQLAlchemy in Blueprint models without reference to the app
Question: I'm trying to create a "modular application" in Flask using Blueprints.

When creating models, however, I'm running into the problem of having to
reference the app in order to get the `db`-object provided by Flask-
SQLAlchemy. I'd like to be able to use some blueprints with more than one app
(similar to how Django apps can be used), so this is not a good solution.*

  * It's possible to do a switcharoo, and have the Blueprint create the `db` instance, which the app then imports together with the rest of the blueprint. But then, any other blueprint wishing to create models need to import from **that** blueprint instead of the app.

My questions are thus:

  * Is there a way to let Blueprints define models without any awareness of the app they're being used in later -- and have several Blueprints come together? By this, I mean having to import the app module/package from your Blueprint.
  * Am I wrong from the outset? Are Blueprints not meant to be independent of the app and be redistributable (à la Django apps)? 
    * If not, then what pattern _should_ you use to create something like that? Flask extensions? Should you simply not do it -- and maybe centralize all models/schemas à la Ruby on Rails?

> _Edit_ : I've been thinking about this myself now, and this might be more
> related to SQLAlchemy than Flask because you have to have the
> `declarative_base()` when declaring models. And _that's_ got to come from
> somewhere, anyway!
>
> Perhaps the best solution is to have your project's schema defined in one
> place and spread it around, like Ruby on Rails does. Declarative SQLAlchemy
> class definitions are really more like schema.rb than Django's models.py. I
> imagine this would also make it easier to use migrations (from
> [alembic](http://pypi.python.org/pypi/alembic/) or [sqlalchemy-
> migrate](http://code.google.com/p/sqlalchemy-migrate/)).

* * *

I was asked to provide an example, so let's do something simple: Say I have a
blueprint describing "flatpages" -- simple, "static" content stored in the
database. It uses a table with just shortname (for URLs), a title and a body.
This is `simple_pages/__init__.py`:

    
    
    from flask import Blueprint, render_template
    from .models import Page
    
    flat_pages = Blueprint('flat_pages', __name__, template_folder='templates')
    
    @flat_pages.route('/<page>')
    def show(page):
        page_object = Page.query.filter_by(name=page).first()
        return render_template('pages/{}.html'.format(page), page=page_object)
    

Then, it would be nice to let this blueprint define its own model (this in
`simple_page/models.py`):

    
    
    # TODO Somehow get ahold of a `db` instance without referencing the app
    # I might get used in!
    
    class Page(db.Model):
        name = db.Column(db.String(255), primary_key=True)
        title = db.Column(db.String(255))
        content = db.Column(db.String(255))
    
        def __init__(self, name, title, content):
            self.name = name
            self.title = title
            self.content = content
    

* * *

This question is related to:

  * [Flask-SQLAlchemy import/context issue](http://stackoverflow.com/questions/9692962/flask-sqlalchemy-import-context-issue)
  * [What's your folder layout for a Flask app divided in modules?](http://stackoverflow.com/questions/6089020/whats-your-folder-layout-for-a-flask-app-divided-in-modules?rq=1)

And various others, but all replies seem to rely on import the app's `db`
instance, or doing the reverse. The ["Large app how
to"](https://github.com/mitsuhiko/flask/wiki/Large-app-how-to) wiki page also
uses the "import your app in your blueprint" pattern.

* Since the official documentation shows how to create routes, views, templates and assets in a Blueprint without caring about what app it's "in", I've assumed that Blueprints should, in general, be reusable across apps. However, this modularity doesn't seem _that_ useful without also having independent models.

Since Blueprints can be hooked into an app more than once, it might simply be
the wrong approach to have models in Blueprints?


Answer: I believe the truest answer is that modular blueprints shouldn't concern
themselves directly with data access, but instead rely on the application
providing a compatible implementation.

So given your example blueprint.

    
    
    from flask import current_app, Blueprint, render_template
    
    flat_pages = Blueprint('flat_pages', __name__, template_folder='templates')
    
    @flat_pages.record
    def record(state):
        db = state.app.config.get("flat_pages.db")
    
        if db is None:
            raise Exception("This blueprint expects you to provide "
                            "database access through flat_pages.db")
    
    @flat_pages.route('/<page>')
    def show(page):
        db = current_app.config["flat_pages.db"]
        page_object = db.find_page_by_name(page)
        return render_template('pages/{}.html'.format(page), page=page_object)
    

From this, there is nothing preventing you from providing a default
implementation.

    
    
    def setup_default_flat_pages_db(db):
        class Page(db.Model):
            name = db.Column(db.String(255), primary_key=True)
            title = db.Column(db.String(255))
            content = db.Column(db.String(255))
    
            def __init__(self, name, title, content):
                self.name = name
                self.title = title
                self.content = content
    
        class FlatPagesDBO(object):
            def find_page_by_name(self, name):
                return Page.query.filter_by(name=name).first()
    
        return FlatPagesDBO()
    

And in your configuration.

    
    
    app.config["flat_pages.db"] = setup_default_flat_pages_db(db)
    

The above could be made cleaner by not relying in direct inheritance from
db.Model and instead just use a vanilla declarative_base from sqlalchemy, but
this should represent the gist of it.

