Nsryjdtyk

In the past months I've written half a dozen of little flask/sqlalchemy applications, and it looks like I'll keep going. They're mostly independent intranet tools giving views and evaluations of data in various company databases. I have one blueprint with basically the company logo, a style sheet and some common views (login/logout). So a typical app follows this boilerplate pattern:

if (production_environment):

    engine_1 = create_engine(uri_1)

    engine_2 = create_engine(uri_2)

    engine_3 = create_engine(uri_3)

else: # offline the intranet

    engine_1 = create_engine(devel_server)

    # etc.



Session_1 = sessionmaker(...)

Session_2 = sessionmaker(...)

Session_3 = sessionmaker(...)



app = Flask("some_app")

app.register_blueprint(company_layout)

# this is needed for the company blueprint template to display the

# title of the app in the top title bar

app.config['TITLE'] = "Some App"



@app.route('/')

def index():

    db1 = Session_1

    db2 = Session_2

    ... you get the gist.

Now that's a lot of boilerplate code. At first I thought to factor out all this config and database setup stuff into a separate module with the sessionmakers and a function that would and return a fully set-up app. But that still leaves me with a lot of separate apps all of which need to be given their own entry points at the webserver/wsgi level, and also they can't link to one another in a development server.

From the flask docs I understand that the way to deal with this situation is to factor out all the little apps into individual blueprints, then create one centrally configured main app and registering all blueprints on it. I've tried it, and it works as expected. But there are a few things I either can't figure out, or seem to have figured out in a strange 'this isn't how this is meant to work' fashion.

Number one: I want the blueprint to set its own title to be displayed in the top layout template. Right now I'm using the config['TITLE'] hack to do that. Is this what a context processor is meant to be used for?

Number two: The databases. The sqlalchemy docs say that engines and sessionmaker are supposed to be set up once outside the app/request context and create/close session on a per-request level (the way I'm doing this now). This seems to contradict the flask documentation which suggests database URIs be set in the app's config (which elegantly solves the production/development distinction). However, this means that the entire database infrastructure needs to be set up and torn down on each and every request because everything happens inside the app context. Then I'd somehow need to create all engine and sessionmakers in the main app module, somehow pass them down to the blueprints, and have the blueprint make the Sessions that it needs. How do I do that? Somehow use the 'g' object? Doesn't this induce siginificant overhead?

Anyway, as you can see I'm a little stuck on the architectural side of my site and I'd appreciate anly suggestions. Thanks.

PS: I've read the app factory docs at pooco,org but couldn't make enough sense of it to decide if it helps me with my problem. I'm not using Flask-SQLAlchemy because I can't tell what it is good for. Almost all of the documentation just repeats database model design stuff from SQLAlchemy but doesn't explain any benefits of using Flask-SQLAlchemy over vanilla SQLAlchemy with scoped_session. What is seems to do is make a lot of the underlying SQLalchemy mechanics invisible in ways I don't understand.