On Aug 22, 2012, at 7:51 AM, David McKeone wrote: > I've been using SQLAlchemy with Flask via the Flask extension > Flask-SQLAlchemy. Everything works great so far, but I foresee a potential > problem once I start to use my database model outside of Flask. In the > future I'd like to be able to use my models with non-Flask SQLAlchemy (a > worker daemon process or with a PySide interface). "Well just use standard > SQLAlchemy," you may say, " and fore-go the use of the extension". That was > my first thought, but sadly some useful extensions (notably > Flask-DebugToolbar) seem to like using the extension version and it is nice > to be able to have Flask manage the database sessions in the way that it > does. I'd like to not throw the baby out with the bath water. > > I realize that this is somewhat specific to Flask, but is there a way that I > could do both? Can I create models with standard SQLAlchemy declarative and > then somehow inject them into Flask-SQLAlchemy's way of doing things? > > If it helps with the solution, I don't need to use any of the Model specific > methods that Flask-SQLAlchemy provides (get_or_404, paginate, etc..) and I > also specify a __tablename__ for all of my models, so I don't rely on > Flask-SQLAlchemy generating that for me. > > I took a look at the source of Flask-SQLAlchemy > (https://github.com/mitsuhiko/flask-sqlalchemy/blob/master/flask_sqlalchemy.py) > and from what I can tell it seems that it's using Flask's signalling > capabilities by customizing SQLAlchemy's session and mapper, but that is > where my understanding ends (I'm still new to this whole stack, Python, > Flask, SQLAlchemy) and I could use some pointers for how to proceed.
There's no reason I can see in the source that flask-sqlalchemy would get in the way of entirely plain SQLAlchemy mapped objects. At the end of the day, a class that extends Flask's db.model is just a mapped class, just like a non-"flask" class. Both kinds of classes are freely usable with any SQLAlchemy Session, including the Session that Flask-SQLA provides. It's important to note the distinction between mapper configuration, which has to do with class structure, and session configuration, which only deals with instances of objects. These two processes work together at a core level that various extensions only ride on top of, unless those extensions define additional dependencies above that level. Flask-sqlalchemy appears only to define one very trivial such dependency which is some coordination to enable the before_models_committed and models_committed hooks, which themselves are just for end-user convenience (http://packages.python.org/Flask-SQLAlchemy/signals.html). The Flask-SQLA approach is really just assigning event listeners to sessions and mappers. It's doing so in a way that is a bit brittle, but also this system precedes SQLAlchemy's 0.7 event model. Armin's immediate goal with flask-sqlalchemy is to migrate the extension to use the new event model, which would actually remove the need for the styles of registration I see here as the new system allows registration of event listeners on all sessions/mappers non-intrusively. There's also a custom Query class in use here, though it doesn't seem to be consistently integrated with the Session, but using custom Query classes like this as well as adding the "MyClass.query" hook is a widely used pattern. So if you were to use plain SQLAlchemy models with flask-SQLA out of the box, these particular events wouldn't fire off as much, unless you also set up the flask_sqlalchemy._SignalTrackingMapperExtension with your normal mappers. I think if you just tried using regular models with flask models, and didn't rely on those two particular signals, you'd see everything pretty much works without any issue. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
