app.config['SQLALCHEMY_DATABASE_URI'] = 'mysql+pymysql://root:19931218@localhost/test'app.config['SQLALCHEMY_COMMIT_ON_TEARDOWN'] = Truedb = SQLAlchemy(app)class User(db.Model):
__tablename__ = 'user'
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 from sql_learn import db,User
import pymysql
db.create_all()#创建相应的表
#user_Susan = User(username = 'Susan',email = '6666663@qq.com')
#db.session.add(user_Susan)
#user_Susan.username = 'Susan_2'
#db.session.add(user_Susan)
#db.session.commit()
#print(db.session.query(User,User.id,User.username).all())#这里返回的是一个元组,每一个对象还是一个元组,包含User类,id，username
#print(User.query.filter_by(username = 'Susan').all())#flask的查询对象返回User的对象user = User.query.filter_by(username = 'Susan').first()user.username = 'Susan_wifi'db.session.add(user)
db.session.commit()
目录
Session 其实 就是一个会话, 可以和数据库打交道的一个会话
在一般的意义上， 会话建立与数据库的所有对话，并为你在其生命周期中加载或关联的所有对象表示一个“等待区”。他提供了一个入口点获得查询对象， 向数据库发送查询，使用会话对象的当前数据库连接， 将结果行填充在对象中， 然后存储在会话中， 在这种结构中称为身份映射 – 这种数据结构维护了每一个副本的唯一， 这种唯一意味着一个对象只能有一个特殊的唯一主键。
会话以基本无状态的形式开始，一旦发出查询或其他对象被持久化，它就会从一个引擎申请连接资源，该引擎要么与会话本身相关联，要么与正在 *** 作的映射对象相关联。此连接标识正在进行的事务， 在会话提交或回滚其挂起状态之前，该事务一直有效。
会话中维护的所有变化的对象都会被跟踪 - 在再次查询数据库或提交当前事务之前， 它将刷新对数据库的所有更改， 这被称为工作模式单元。
在使用会话时候，最重要的是要注意与它相关联的对象是会话所持有的事务的代理对象 - 为了保持同步，有各种各样的事件会导致对象重新访问数据库。可能从会话中分离对象并继续使用他们，尽管这种做法有其局限性。但是通常来说，当你希望再次使用分离的对象时候，你会将他们与另一个会话重新关联起来， 以便他们能够恢复表示数据库状态的正常任务。
可能会将这里的session与http中的session搞混，需要注意的是，它有点用作缓存，因为它实现了 身份映射 模式，并存储了键入其主键的对象。但是，它不执行任何类型的查询缓存。 此外，默认情况下，Session使用弱引用存储对象实例。这也违背了将Session用作缓存的目的。关于session强应用下次再讨论。
1. session创建和管理数据库连接的会话 2. model object 通过session对象访问数据库，并把访问到的数据以 Identity Map 的方式，映射到Model object 中
1. session在刚被创建的时候，还没有和任何model object 绑定，可认为是无状态的 2. session 接受到query查询语句, 执行的结果或保持或者关联到session中 3. 任意数量的model object被创建，并绑定到session中，session会管理这些对象 4. 一旦session 里面的objects 有变化，那可是要commit/rollback提交或者放弃changs
一般来说，session在需要访问数据库的时候创建，在session访问数据库的时候，准确来说，应该是“add/ update / delete ”数据库的时候，会开启 database transaction 。 假设没有修改autocommit的默认值( False ), 那么， database transaction 一直会保持，只有等到 session 发生rolled back、committed、或者closed的时候才结束，一般建议，当 database transaction 结束的时候，同时 close session ,以保证，每次发起请求，都会创建一个新的 session 特别是对web应用来说，发起一个请求，若请求使用到 Session 访问数据库，则创建 session ，处理完这个请求后，关闭 session
Session 是一个直接实例化的常规的Python 类。然而， 为了标准会会话的配置和获取方式， sessionmaker 类通常用于创建顶级会话配置， 然后可以在整个应用程序中使用它， 就不需要重复配置参数。
下面是sessionmaker 的使用方式
在上面，该 sessionmaker()创建了一个工厂类，在创建这个工厂类时我们配置了参数绑定了引擎。将其赋值给Session。每次实例化Session都会创建一个绑定了引擎的Session。 这样这个session在访问数据库时都会通过这个绑定好的引擎来获取连接资源当你编写应用程序时， 请将sessionmaker 工厂放在全局级别，视作应用程序配置的一部分。例如：应用程序包中有三个.py文件，您可以将该sessionmaker行放在__init__.py文件中在其他模块“from mypackage import Session”。这样，所有的Session()的配置都由该配置中心控制。
直接只用 create_engine 时，就会创建一个带连接池的引擎：
创建一个session，连接池会分配一个connection。当session在使用后显示地调用 session.close()，也不能把这个连接关闭，而是由由QueuePool连接池管理并复用连接。
确保 session 在使用完成后用 session.close、session.commit 或 session.rollback 把连接还回 pool，这是一个必须在意的习惯。
关于SQLAlchemy 数据库连接池：
session 和 connection 不是相同的东西， session 使用连接来 *** 作数据库，一旦任务完成 session 会将数据库 connection 交还给 pool。 在使用 create_engine 创建引擎时，如果默认不指定连接池设置的话，一般情况下，SQLAlchemy 会使用一个 QueuePool 绑定在新创建的引擎上。并附上合适的连接池参数
create_engine() 函数和连接池相关的参数有：
SQLAlchemy不使用连接池：在创建引擎时指定参数 poolclass=NullPool 即禁用了SQLAlchemy提供的数据库连接池。SQLAlchemy 就会在执行 session.close() 后立刻断开数据库连接。当然，如果没有被调用 session.close()，则数据库连接不会被断开，直到程序终止。
关于 SQLAlchemy 的 engine ,这里有一篇文章写的很好： http://sunnyingit.github.io/book/section_python/SQLalchemy-engine.html
session不是线程安全的，在多线程的环境中，默认情况下，多个线程将会共享同一个session。试想一下，假设A线程正在使用session处理数据库，B线程已经执行完成，把session给close了，那么此时A在使用session就会报错，怎么避免这个问题？
1 . 可以考虑在这些线程之间共享Session及其对象。但是应用程序需要确保实现正确的锁定方案，以便多个线程不会同时访问Session或其状态。SQLAlchemy 中的 scoped_session 就可以证线程安全，下面会有讨论。 2 . 为每个并发线程维护一个会话，而不是将对象从一个Session复制到另一个Session，通常使用Session.merge()方法将对象的状态复制到一个不同Session的新的本地对象中。
上面简单介绍了sessionmaker的作用，下面开始探讨 scoped_session 对创建 Session 的影响。现在先探讨单线程情况。
结论：
通过 sessionmaker 工厂创建了两个 Session ，而且可以看到 s1 s2 是两个不同的 Session 。 在 s1 添加 person 后，继续使用 s2 添加 person 报错. 说 person 这个对象 已经和 另一个 Session 关联一起来了, 所以再次关联另一个 Session 就会报错。
即在上面代码的 s1.add(person) 之后， s1.commit() ,然后再 s2.add(persion)这里就没帖代码了。
结论：
即使在 s1 提交之后， s2 再去添加 person 也会发生错误,但 s1 的提交是成功了的，数据 person 已经存放在数据库了。 当 s1 添加 person 并提交，然后关闭 s1 , s2 再去添加并提交 person 数据库,这不会报错，但是数据库也不会出现两条 person 数据。
结论：
s1 关闭之后， s2 再去添加提交同一个对象，不会报错，但是数据库值有一条 person 数据。
结论：
当然， s1 , s2 添加提交不同的对象，不会出错。在数据库成功新增数据。
以上说明：
一个对象一旦被一个 Session 添加，除非关闭这个 Session ，不然其他的 Session 无法添加这个对象。 一个 Session 添加并提交一个对象，然后关闭该 Session ，其他的 Session 可以添加并提交这个对象，但是数据库并不会有这条数据。
结论：
可以看到，通过 scoped_session再去创建 Session ，返回的是同一个 Session 。 scoped_session类似单例模式，当我们调用使用的时候，会先在Registry里找找之前是否已经创建Session，未创建则创建 Session ，已创建则直接返回。
这里探讨在多线程下使用 scoped_session 与不使用 scoped_session 的情况
当不使用 scoped_session 时，也分两种情况，是否创建全局性 Session
结论：
每个线程下的 Session 都是不同的 Session 数据库成功新增了线程3提交的数据，其他的线程中的数据并没有提交到数据库中去。
结论：
全部线程下的 Session 都时同一个 Session 每个线程下的数据都被提交到了数据库
结论：
每个线程下的 Session 都不相同 只有线程3下的数据被提交到了数据库
结论：
每个线程下的 Session 是同一个 Session 每个线程下的数据都没提交到了数据库
以上说明：
在同一个线程中，有 scoped_session 的时候，返回的是同一个 Session 对象。 在多线程下，即使通过 scoped_session 创建Session，每个线程下的 Session 都是不一样的，每个线程都有一个属于自己的 Session 对象，这个对象只在本线程下共享。 scoped_session 只有在单线程下才能发挥其作用。在多线程下显得没有什么作用。
#看例子：node = Node()
node.name = 'name'
db.session.add(node)
db.session.flush() # 主要是这里，写入数据库，但是不提交
this_id = node.id # 这样就可以获得自增id了
db.session.commit()
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）