On Wednesday, August 22, 2012 9:03:55 PM UTC+1, Michael Bayer wrote: > > > On Aug 22, 2012, at 3:51 PM, David McKeone wrote: > > > I was wondering if you could just clarify how I might convert a standard > model object into a flask-sqlalchemy model object. > > > why do you need to do this ? What flask-sqlalchemy-specific features > would you hope for the model objects to have ? There's pretty much two I > can see - one is the MyModel.query attribute, and the other are the events. > Neither are necessary, though you might want the usage of one or the > other. Otherwise no "conversion" is needed. > > > 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? > > > I don't see why engine or session would be stuck onto the model class like > that, I don't see that usage here: > http://packages.python.org/Flask-SQLAlchemy/quickstart.html#a-minimal-application. > > Just the "query" attribute. "User.query.all()". This is equivalent to > "session.query(User).all()". > > The "User.session / User.engine" pattern suggests that a model class acts > as a registry for how to get at a live database connection. That pattern > is one that SQLAlchemy specifically discourages. In the Flask docs, > you'll see that the "handle" to the state of a transaction is db.session. > The objects like instances of User are then contained within that. > > > 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. > > > its really quite a small amount of effort. I think for now the strategy > on your end should be to forge ahead with what's there, and if there's some > very specific thing that doesn't work as you expect, I can show you how to > get the behavior you're looking for. > > > I suppose I should be more clear. This is really a long term question, I was just looking for some kind of answer now because I don't want to code myself into a corner in the short term. Currently I can make requests outside of a flask request context by using the app.test_request_context() context manager, and it seems to do the right thing.
In the long term I'm looking for 2 (maybe 3) things that I already get from Flask-SQLAlchemy: 1) Session teardown for every request (looks like that is done with a call to session.remove() in the request teardown) 2) Debug query tracking for use with Flask-DebugToolbar (Plus compatibility with other plug-ins that may expect Flask-SQLAlchemy) - This is really the difficult one. In this case I think it just needs an attribute on the Flask app called sqlalchemy_queries which contains a tuple of queries. This is where I was thinking it may be better to assist with updating the plugin to just play nice with SQLAlchemy's default behaviours. Maybe I'm wrong? 3) The Model.query behaviour (it's nice, but I could live without it, since its really just syntactic) I think it'll make my code simpler/better for two reasons: 1) My models will be SQLAlchemy, not a Flask specific dialect with db <dot> everywhere. This will make the SQLAlchemy documentation more obvious to programmers that use the code. 2) The db.Model method seems to make it very easy to create circular import errors (as seen in this issue: https://github.com/mitsuhiko/flask-sqlalchemy/issues/97 and experienced by myself). It would be really nice if I could isolate the models and model mapping behaviours from the rest of the application to avoid that kind of thing. The "User.session / User.engine" pattern suggests that a model class acts > as a registry for how to get at a live database connection. That pattern > is one that SQLAlchemy specifically discourages. In the Flask docs, > you'll see that the "handle" to the state of a transaction is db.session. > The objects like instances of User are then contained within that. This was really just my lack of understanding of how the database connection is connected to the models, rather than stating how I wanted it to be done. Thinking about it now, and reading your comment, I realize that sessions are connected to the models when they are passed in, like in session.query(User).first(), and Model.query is really just a class instance that holds onto the session. Duh, sorry. I really need to read through the docs so I can be more comprehensible. I'm attempting to read as I go so that my questions are better, but it's not quite working out yet. Thank you for your help (and understanding) though. -- 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/-/ZEhaT7wAhX4J. 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.
