forked from orbit-oss/flask
Proofreading the documentation
This commit is contained in:
parent
4ff9493e57
commit
a7ff9dbddd
8 changed files with 58 additions and 58 deletions
|
|
@ -48,12 +48,12 @@ What did we gain from this? Now we can restructure the application a bit
|
|||
into multiple modules. The only thing you have to remember is the
|
||||
following quick checklist:
|
||||
|
||||
1. the `Flask` application object creation have to be in the
|
||||
1. the `Flask` application object creation has to be in the
|
||||
`__init__.py` file. That way each module can import it safely and the
|
||||
`__name__` variable will resole to the correct package.
|
||||
`__name__` variable will resolve to the correct package.
|
||||
2. all the view functions (the ones with a :meth:`~flask.Flask.route`
|
||||
decorator on top) have to be imported when in the `__init__.py` file.
|
||||
Not the objects itself, but the module it is in. Do the importing at
|
||||
Not the object itself, but the module it is in. Do the importing at
|
||||
the *bottom* of the file.
|
||||
|
||||
Here an example `__init__.py`::
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ SQLAlchemy in Flask
|
|||
Many people prefer `SQLAlchemy`_ for database access. In this case it's
|
||||
encouraged to use a package instead of a module for your flask application
|
||||
and drop the models into a separate module (:ref:`larger-applications`).
|
||||
Although that is not necessary but makes a lot of sense.
|
||||
While that is not necessary, it makes a lot of sense.
|
||||
|
||||
There are three very common ways to use SQLAlchemy. I will outline each
|
||||
of them here:
|
||||
|
|
@ -52,7 +52,7 @@ automatically remove database sessions at the end of the request for you::
|
|||
db_session.remove()
|
||||
return response
|
||||
|
||||
Here an example model (put that into `models.py` for instance)::
|
||||
Here is an example model (put this into `models.py`, e.g.)::
|
||||
|
||||
from sqlalchemy import Column, Integer, String
|
||||
from yourapplication.database import Base
|
||||
|
|
@ -70,7 +70,7 @@ Here an example model (put that into `models.py` for instance)::
|
|||
def __repr__(self):
|
||||
return '<User %r>' % (self.name, self.email)
|
||||
|
||||
You can insert entries into the database like this then:
|
||||
You can insert entries into the database like this:
|
||||
|
||||
>>> from yourapplication.database import db_session
|
||||
>>> from yourapplication.models import User
|
||||
|
|
@ -95,11 +95,11 @@ Manual Object Relational Mapping
|
|||
Manual object relational mapping has a few upsides and a few downsides
|
||||
versus the declarative approach from above. The main difference is that
|
||||
you define tables and classes separately and map them together. It's more
|
||||
flexible but a little more to type. In general it works similar to the
|
||||
flexible but a little more to type. In general it works like the
|
||||
declarative approach, so make sure to also split up your application into
|
||||
multiple modules in a package.
|
||||
|
||||
Here the example `database.py` module for your application::
|
||||
Here is an example `database.py` module for your application::
|
||||
|
||||
from sqlalchemy import create_engine, MetaData
|
||||
from sqlalchemy.orm import scoped_session, sessionmaker
|
||||
|
|
@ -112,7 +112,7 @@ Here the example `database.py` module for your application::
|
|||
def init_db():
|
||||
metadata.create_all(bind=engine)
|
||||
|
||||
As for the declarative approach you need to close down the session after
|
||||
As for the declarative approach you need to close the session after
|
||||
each request. Put this into your application module::
|
||||
|
||||
from yourapplication.database import db_session
|
||||
|
|
@ -122,7 +122,7 @@ each request. Put this into your application module::
|
|||
db_session.remove()
|
||||
return response
|
||||
|
||||
Here an example table and model (put that into `models.py` for instance)::
|
||||
Here is an example table and model (put this into `models.py`)::
|
||||
|
||||
from sqlalchemy import Table, Column, Integer, String
|
||||
from sqlalchemy.orm import mapper
|
||||
|
|
@ -172,7 +172,7 @@ connection first so that we can use a transaction:
|
|||
|
||||
SQLAlchemy will automatically commit for us.
|
||||
|
||||
To query your database, yu use the engine directly or use a connection:
|
||||
To query your database, you use the engine directly or use a connection:
|
||||
|
||||
>>> users.select(users.c.id == 1).execute().first()
|
||||
(1, u'admin', u'admin@localhost')
|
||||
|
|
@ -183,7 +183,7 @@ These results are also dict-like tuples:
|
|||
>>> r['name']
|
||||
u'admin'
|
||||
|
||||
You can also pass string of SQL statements to the
|
||||
You can also pass strings of SQL statements to the
|
||||
:meth:`~sqlalchemy.engine.base.Connection.execute` method:
|
||||
|
||||
>>> engine.execute('select * from users where id = :1', [1]).first()
|
||||
|
|
|
|||
|
|
@ -3,12 +3,12 @@
|
|||
Using SQLite 3 with Flask
|
||||
=========================
|
||||
|
||||
In Flask you can implement opening of dabase connections at the beginning
|
||||
In Flask you can implement opening of database connections at the beginning
|
||||
of the request and closing at the end with the
|
||||
:meth:`~flask.Flask.before_request` and :meth:`~flask.Flask.after_request`
|
||||
decorators in combination with the special :class:`~flask.g` object.
|
||||
|
||||
So here a simple example how you can use SQLite 3 with Flask::
|
||||
So here a simple example of how you can use SQLite 3 with Flask::
|
||||
|
||||
import sqlite3
|
||||
from flask import g
|
||||
|
|
@ -70,7 +70,7 @@ Initial Schemas
|
|||
|
||||
Relational databases need schemas, so applications often ship a
|
||||
`schema.sql` file that creates the database. It's a good idea to provide
|
||||
a function that creates the database bases on that schema. This function
|
||||
a function that creates the database based on that schema. This function
|
||||
can do that for you::
|
||||
|
||||
from contextlib import closing
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue