塔架和金字塔的会话差异

Question

作为Pylons用户,我正试图切换到金字塔,现在试图理解差异.

在Pylons中,我习惯于将Session定义myproj.model.meta为:

Session = scoped_session(sessionmaker())

然后导入它myproj.model来定义模型,然后在app中引用:

root = Session.query(MyModel).filter(...)...

现在使用Pyramid中的默认模板(pyramid_routesalchemy)我像以前一样定义Session(除了调用它DBSession并添加扩展名):

DBSession = scoped_session(sessionmaker(extension=ZopeTransactionExtension()))

但在views.py我不直接使用它但实例化它:

dbsession = DBSession()
root = dbsession.query(MyModel).filter(...)...

为什么？有什么区别？

而且,与金字塔有什么不同

import transaction
...
model = MyModel(name=u'root', value=55)
session.add(model)
session.flush()
transaction.commit()

到Pylons

model = MyModel(name=u'root', value=55)
session.add(model)
session.commit()

Answer 1

实际上,您查找sqlalchemy会话实例进行查询的方式与塔架和/或金字塔没有任何关系.Pylons可能已经建议将其中一种方式作为"标准"挂架方式,但就是这样.您获得会话的方式之间唯一真正的区别在于使用ZopeTransactionExtension的示例.

ZopeTransactionExtension是一个小块,可确保打开的每个会话都加入一个活动事务.因此,如果您打开5个会话,他们将加入相同的交易.这样,如果您提交或回滚事务,则5个会话中的任何一个完成的所有工作都将效仿.事务模块("transaction.commit()")在这里是关键.

pyramid_tm尝试简单地设置事务...它在请求输入时启动一个,所有作用域数据库会话加入它...然后在请求结束时,如果它发现错误,它将回滚事务.否则,将提交事务.这样,视图级代码就不必手动创建或关闭/提交/回滚事务.

session.flush()主要用于确保数据库模型实例在不提交事务的情况下填充其主键.

所以你要做的就是:

def myview(request):
    session = DBsession()
    session.add(model)

pyramid_tm将确保会话已正确提交或回滚.