On Wednesday, August 22, 2012 10:21:59 PM UTC+1, David McKeone wrote: > > > > 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. > >
Didn't say this explicitly; for now I will do what you say and forge ahead with things. I think I see the path, but I'll make sure to let you (the list) know if I run into trouble. Thanks again. -- 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/-/9_cMuOcTTdMJ. 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.
