Instead of flask-peewee I'm using plain peewee package.
Here's the way I'm initializing the database:
import os
# just extending the BaseFlask with yaml config reader
from . extensions.flask_app import Flask
# peewee's wrapper around the database
from playhouse.flask_utils import FlaskDB
db_wrapper = FlaskDB()
# define the application factory
def create_app(env):
app = Flask(__name__)
# load config depending on the environment
app.config.from_yaml(os.path.join(app.root_path, 'config.yml'), env)
# init extensions
db_wrapper.init_app(app)
# ...
I know that I should call this to create tables:
from . models import User
db_wrapper.database.connect()
db_wrapper.database.create_tables([User])
But where do I put the table creation code, so that the database would be already initialized?
Edit
Looking at the docs I found out that I can use User.create_table(fail_silently=True) like that:
# in app/__init__.py
# define the application factory
def create_app(env):
app = Flask(__name__)
# load config depending on the environment
app.config.from_yaml(os.path.join(app.root_path, 'config.yml'), env)
# init extensions
db_wrapper.init_app(app)
create_tables();
# rest of the initialization
def create_tables():
from . models import User
User.create_table(fail_silently=True)
Is it alright to do it here? Or is there a better way/tool for this?
Edit
Figured it out. Please, see my answer below.
Update
I didn't know about the built-in CLI support in Flask. I don't know whether you should consider such an approach at all, since you can do things out of the box (see documntation).
I can utilize the flask-script package. I've done it before, just overlooked it.
Activate your virtual environment and run:
pip install flask-script
Then create manage.py file in your root directory, add these lines:
import os
from app import create_app, db_wrapper
from app.models import *
from flask_script import Manager, Shell
# create the application instance
app = create_app(os.getenv('FLASK_ENV', 'development'))
# instantiate script manager
manager = Manager(app)
def make_shell_context():
return dict(app=app, db_wrapper=db_wrapper, User=User)
#manager.command
def run_shell():
Shell(make_context = make_shell_context).run(no_ipython=True, no_bpython=True)
# here's my simple command
#manager.command
def create_tables():
User.create_table(fail_silently=True)
#manager.command
def run_tests():
import unittest
tests = unittest.TestLoader().discover('tests')
unittest.TextTestRunner(verbosity=2).run(tests)
# run it
if __name__ == '__main__':
manager.run()
Related
I'm writing a Flask app and I instantiate a mongo database in main.py.
I've got a submodule called user.py that holds class User. main.py takes login credentials and sends it to the class User which handles the rest.
How can I cleanly pass my mongo instance to the User class? I've tried static variables in a config.py file but they don't work because the variables are always None when user.py tries to use them.
Right now I'm resorting to passing in mongo as a parameter, but this seems like a dirty way to do it considering there will be many modules. Here's my code;
# Setup app and database
app = Flask(__name__)
app.config['MONGO_URI'] = 'mongodb://'
mongo = PyMongo(app)
You can import mongo directly into your user.py module.
To avoid circular import error, you just have to move the imports to the bottom of the file. As long as you import User into main after app is defined, it should resolve the circular import:
user.py
from .main import mongo
# class User():
# ... Your Code
main.py
from flask import Flask
from flask_pymongo import PyMongo
app = Flask(__name__)
mongo = PyMongo(app)
from .user import User
Moving imports to the bottom are normally not a good idea, but in Flask is quite common. Below is an example of a similar scenario from the official flask documentation:
# app.py
from flask import Flask
app = Flask(__name__)
import app.views
# views.py
from app import app
#app.route('/')
def index():
return 'Hello World!'
http://flask-.readthedocs.io/en/0.6/patterns/packages/#simple-packages
Do the importing at the bottom of the file [...]
Every Python programmer hates them, and yet we just added some: circular imports (That’s when two modules depend on each other. In this case views.py depends on init.py). Be advised that this is a bad idea in general but here it is actually fine. The reason for this is that we are not actually using the views in init.py and just ensuring the module is imported and we are doing that at the bottom of the file.
I have a project and I've defined my db.py module as:
app = get_global_flask_app()
app.config['SQLALCHEMY_DATABASE_URI'] = "postgresql://foo:bar#127.0.0.1:5432/test"
app.config["SQLALCHEMY_TRACK_MODIFICATIONS"] = False
db = SQLAlchemy(app)
db.create_all()
Then I import db.db into modules that need to query the database and insert data (db.session.query()).
However, this means that when I write test code (pytest) to test any module that imports db.py, I will need to define "SQLALCHEMY_DATABASE_URI". One solution is to have db be a lazy attribute so that the code above is executed in tests only if the database is used/tested. Is there a common design pattern for Flask() + SQLA + SQLALCHEMY_DATABASE_URI out there that I'm missing? How would you solve this problem? Flask-config?
The way we normally solve this problem is with an application factory and a config.
This means you have a function somewhere in your project that looks something like this (taken from the documentation with modifications):
def create_app(config_filename, settings_override=None):
app = Flask(__name__)
app.config.from_pyfile(config_filename)
app.config.from_object(settings_override)
from yourapplication.model import db
db.init_app(app)
from yourapplication.views.admin import admin
from yourapplication.views.frontend import frontend
app.register_blueprint(admin)
app.register_blueprint(frontend)
return app
Then (and hopefully you're using pytest) in your root test directory, you have a conftest file which automatically prepares your test environment something like this:
import pytest
from your_project import create_app
class TestConfig:
SQLALCHEMY_DATABASE_URI = "postgresql://foo:bar#127.0.0.1:5432/test"
SQLALCHEMY_TRACK_MODIFICATIONS = False
ANY OTHER SETTINGS...
#pytest.fixture(autouse=True)
def app(request):
app = create_app(settings_override=TestConfig)
ctx = app.app_context()
ctx.push()
def teardown():
ctx.pop()
request.addfinalizer(teardown)
return app
Typically, we create another fixture which is also autouse=True that handles that DB set-up, flush, and possibly loading fixtures, and only use that fixture in tests which need to access the DB (integration or functional tests), which means simply that we include in a conftest file in the same directory as our integration tests.
In order to simplify the __init__.py main module, I want to push helper functionality to a different file/class. This requires passing many flask extensions instances when initializing the class, which seems inelegant. My current structure is as follows:
__init__.py:
from flask import Flask, render_template,request
from flask.ext.sqlalchemy import SQLAlchemy
from flask_mail import Mail
from FEUtils import FEUtils
# .. and more imports of various extensions ..
db = SQLAlchemy()
app = Flask(__name__)
db.init_app(app)
mail = Mail(app)
fe_utils = FEUtils(db,mail,app.config)
# Flask code..
if __name__ == '__main__':
app.run()
and FEUtils.py:
from models import User
class FEUtils(object):
def __init__(self,db,mail,config):
self.session = db.session # to access database
self.mail = mail # to send emails
self.config = config # to access app config dictionary
def count_users(self): # example helper method
return self.session.query(User).count()
This all works fine, but seems cumbersome. I'd like the helper class to inherit the various extension instances from the main module, and be able to access the flask config parameters from within the helper class, without passing each when the helper class is instantiated.
Asked differently, is there a way to have the helper class behave as if each of its methods was defined in the main module in an elegant way?
I am using an app factory to initialize my app. In it, I import all the blueprints and register them one by one. Is there a way I can move the import and register statements to a different file or inform the factory about them without referencing them all individually?
def create_app(config_filename):
app = Flask(__name__)
app.config.from_object(config_filename)
from app.users.models import db
db.init_app(app)
from app.users.views import users
from app.posts.views import posts
app.register_blueprint(posts, url_prefix='/posts')
app.register_blueprint(users, url_prefix='/users')
return app
In my project I'm actually generating the blueprints with another script, so I'd like to be able to generate the registration too by appending to a file or something, rather than trying to modify code in the factory.
Yes, you can import and register the blueprints in some other module. But there's no practical point to this approach, it just moves the imports and register calls somewhere else.
myapp/blueprints.py:
from app.users.views import users
from app.posts.views import posts
def init_app(app):
app.register_blueprint(users, prefix='/users')
app.register_blueprint(posts, prefix='/posts')
myapp/__init__.py:
def create_app():
app = Flask(__name__)
# ...
from myapp import blueprints
blueprints.init_app(app)
# ...
Something more useful might be to tell the app what packages to import from and have the app expect to find a blueprint in some standard location for each package. Assuming the blueprint variable will always have the same name as the package, is defined in views, and has the same prefix as the name:
from werkzeug.utils import import_string
def create_app():
app = Flask(__name__)
# ...
for name in ('users', 'posts'):
bp = import_string('myapp.{0}.views:{1}'.format(name, name))
app.register_blueprint(bp, prefix='/{0}'.format(name))
# ...
I'm making a simple Flask web application for fun and I wanted to use nosetests. I'm stuck at how to use Flask-SQLAlchemy to connect to an in-memory test database in my tests file. When I run my tests - Flask connects to my main app's database and what is more, fails to clean it up after each test. Here's my tests code:
import nose
from nose.tools import *
from pyquery import PyQuery as pq
from flask.ext.sqlalchemy import SQLAlchemy
from app import site, db
from app.models import Post
class TestApp(object):
def setUp(self):
site.config['TESTING'] = True
site.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite://'
self.test_app = site.test_client()
db.create_all()
def tearDown(self):
# db.session.remove()
db.drop_all()
def test_posts_index(self):
db.session.add(Post('title', 'body'))
db.session.add(Post('title2', 'body'))
db.session.commit() # this writes to production db ie app.db file
# instead of sqlite://
rv = self.test_app.get('/posts')
d = pq(rv.data)
print len(d('h1'))
assert len(d('h1')) == 2
And here's my app/__init__.py code:
from flask import Flask
from flask.ext.sqlalchemy import SQLAlchemy
from app import config
site = Flask(__name__)
site.config['SQLALCHEMY_DATABASE_URI'] = config.db_uri
db = SQLAlchemy(site)
site.secret_key = 'A0Zr98j/3yX R~XHH!jmN]LWX/,?RT'
from app import db_setup
db_setup.create_db()
import controllers, models
The db_setup.create_db() in app/__init__.py function looks simply like this:
from app import db
from app.models import Post
def create_db():
db.create_all()
db.session.commit()
I tried instantiating the application and database in the tests file, but then my models don't work because they from app import db, where db is the production db object. I also sprinkled a few print statements in the test case like print db and they print out something like <SQLAlchemy engine sqlite://>, but it still writes to the production db anyways.
I'd really appreciate any tips on how to get around this. Thanks!
Why don't you use something about the environment to determine whether the app starts in a testing or live mode?
if 'testing' in os.environ:
site.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite://'
else:
site.config['SQLALCHEMY_DATABASE_URI'] = config.db_uri
There are so many ways to skin this particular cat. If you don't like the idea of having if blocks littering your code you can import your settings from an entirely separate module based on whether the app is started in testing or live mode.
I was able to figure out the problem, it's related to me initiating a connection to the database in my __init__.py file, which I shouldn't do.
The culprit was the
from app import db_setup
db_setup.create_db()
code. Essentially, every time I did an from app import db, I think that app gets instantiated, it calls db_setup.create_db(), which creates the tables using the production config. From there on, despite trying to set the flask app config SQLALCHEMY_DATABASE_URI to an in memory database, the db object would continue to use the database instantiated in the __init__.py file.
All I have to do is call create_all() from the environment my will run in at that time. Hope this helps anyone how might run into something similar.
I had the same problem, but I didn't use a db.create_all() type statement in my init.py file at all.
In the end, the only way I could around the issue was to use
def setUp(self):
with app.app_context():
db.create_all()