On Wednesday, August 22, 2012 2:33:01 PM UTC+1, David McKeone wrote: > > > > On Wednesday, August 22, 2012 2:23:28 PM UTC+1, Simon King wrote: >> >> On Wed, Aug 22, 2012 at 12:51 PM, David McKeone <davidm...@gmail.com> >> 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. >> > >> > >> > To visualize what I'm talking about, here are the two types of models. >> A >> > basic Flask-SQLAlchemy model looks like >> > ( >> http://packages.python.org/Flask-SQLAlchemy/quickstart.html#a-minimal-application): >> >> >> > >> > from flask import Flask >> > from flask.ext.sqlalchemy import SQLAlchemy >> > >> > app = Flask(__name__) >> > app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:////tmp/test.db' >> > >> > db = SQLAlchemy(app) >> > >> > class User(db.Model): >> > id = db.Column(db.Integer, primary_key=True) >> > username = db.Column(db.String(80), unique=True) >> > email = db.Column(db.String(120), unique=True) >> > >> > def __init__(self, username, email): >> > self.username = username >> > >> > self.email = email >> > >> > >> > def __repr__(self): >> > return '<User %r>' % self.username >> > >> > >> > Note the db.Model, db.Integer and db <dot> everything. >> > >> > The plain declarative SQLAlchemy equivalent would be >> > (http://flask.pocoo.org/docs/patterns/sqlalchemy/): >> > >> > >> > from sqlalchemy import Column Integer, String, create_engine >> > from sqlalchemy.orm import scoped_session, sessionmaker >> > from sqlalchemy.ext.declarative import declarative_base >> > >> > engine = create_engine('sqlite:////tmp/test.db', convert_unicode=True) >> > db_session = scoped_session(sessionmaker(autocommit=False, >> autoflush=False, >> > bind=engine)) >> > Base = declarative_base() >> > Base.query = db_session.query_property() >> > >> > >> > class User(Base): >> > __tablename__ = 'users' >> > >> > id = Column(Integer, primary_key=True) >> > name = Column(String(50), unique=True) >> > email = Column(String(120), unique=True) >> > >> > def __init__(self, name=None, email=None): >> > self.name = name >> > self.email = email >> > >> > def __repr__(self): >> > return '<User %r>' % (self.name) >> > >> >> From a very quick read of the Flask-SQLAlchemy docs, I would have >> thought you could just use your flask-based classes in non-Flask-based >> apps without any issue. The quickstart guide that you referenced above >> illustrates a command-line session using them, so there's no reason >> why you couldn't do the same in a worker process. >> >> Have you already tried it and found that it doesn't work? >> >> Simon >> > > > Perhaps I've missed the important bit, but my understanding is that there > are two ways to do it: > > 1) Use SQLAlchemy with manual session control ( > http://flask.pocoo.org/docs/patterns/sqlalchemy/) > 2) Use SQLAlchemy with the Flask-SQLAlchemy extension which does session > control for you, but requires you to use it's own declarative base class, > db.Model ( > http://packages.python.org/Flask-SQLAlchemy/quickstart.html#a-minimal-application > ) > > The problem is that other extensions give you additional features if you > use solution #2, but not if you use solution #1, because solution #1 > implies that you are going to do everything yourself manually. I'm fine > with the way solution #2 handles the sessions and everything else, I just > want to be able to use my own declarative base so that the models are > more-or-less independent of the app that they are being used in. >
I did a re-read of the documentation and I'm guessing this is the part of the documentation you are referring to: http://packages.python.org/Flask-SQLAlchemy/contexts.html That basically says to use: app.test_request_context() before doing what you do, so that it can establish a new context. I suppose that does make sense, I guess i just viewed it as being only for testing and not for application use. I would have thought it might be strange to include Flask in a worker daemon when it isn't actually servicing http requests. -- 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/-/5rIH4VNzWB0J. 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.
