It depends from the use case.

I have following assumptions:

1. Application might want to access blueprint models
2. There can be more than one instance of the blueprint, so there can be multiple instances of the same model mapped to different or same database table(s) (using prefixed table name, etc)
3. Blueprints don't know how they're going to be used in the application - all parameters are passed in object creation time
4. Which brings to the point - blueprints should always dynamicly create their models based on the input parameters to the constructor

For #1, snippet can look like:
something.MyModel.query.all()

I came across this issue with my bugLink project (http://buglink.readthedocs.org/), where the basic app knows about the relationship changeset <-> issue, and extensions to the app should provide release <-> build <-> changeset ( <-> issue).

My understanding of this is that Blueprint are intended to extend the views. If you need to extend the model, you need to define something like a YellowPrint. As the model is highly coupled with the controller, YellowPrint could also have some mechanism in place to extend your controller. But there is no point in extending the controller if you don't make use of the extension provided. Here we come back to the views. Which brings us to the GreenPrint if you need to extend the views and the model.

I don't know if this is exactly the situation you are describing, but I have something that looks like this in Flask-Restless. Check out http://readthedocs.org/docs/flask-restless/en/latest/quickstart.html

Nice work!

There are a few solutions I've seen, depending on the use case:

• Inject dependencies and explicitly generate the views. This use is a good use case for class based views. During init_app, the extension generates the models and passes them to as_view. This is similar to what @jfinkels mentions.
• Provide abstract bases for the models, and expect the user to subclass them and use callbacks to set proxies. Flask-Login does this with UserMixin, login_manager.user_loader, and current_user. This is useful when
• Set properties on the extension instance, then pull them from current_app.extensions['my_ext'].MyModel in views. I don't have an example off the top of my head, but this is a similar concept to Flask-Login's login_manager.anonymous_user.

I'll work on some short examples for each of these solutions to add to the docs on extensions.

Closing as this issue is OLD.

keeping open as this seems important