On Wednesday, August 22, 2012 5:36:22 PM UTC+1, Michael Bayer wrote: > > > 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. > > Thanks for your great response Mike.
Forgive my ignorance, but I don't understand enough of the underpinnings to get my first steps out of this (the downside of starting with something that gives you stuff for free, I suppose). I'm definitely going to walk through what you've said and reference it against the documentation, but while your mind is fresh on the topic, I was wondering if you could just clarify how I might convert a standard model object into a flask-sqlalchemy model object. Using the two examples above, would I just take my User(Base) class and then assign it property out of the Flask db properties? Something like: User.session = db.session() User.engine = db.engine() I know those properties don't actually exist on User, but is that the kind of thing I should be looking to do? Move certain pieces into all of the models? or is there something higher level going on that will do this for me in some way? something else? ... 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. This seems like it would be a really good way to accomplish what I'm looking for and to move things forward as well. Once I read up on the requisite knowledge I may end up making an attempt at making this over the next little while. I had a drink with Armin last week and I'm not sure if his current stuff points him in this direction (of course you'd have to ask him for the real answer on that), but I certainly have a vested interest, so maybe I can do some of the grunt work. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/TOUI90_sC_wJ. 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.
