最近在开发mdwiki的时候遇到这样一个问题.Post is unbond to session.
我就好奇了
post=Post.query.filter_by(location=location).first()
abspath=util.getAbsPostPath(post.location)
tagsList=[]
...
print(post in session) #False
post.tags=tagsList
这样还报post不在session中的错？没有显示调用db.session.commit()啊.
加一行测试：
print(post in session) #False
无奈，一个一个翻post=Post.query.filter_by(location=location).first()到post.tags=tagsList之间调用的每一个函数，终于在util.getAbsPostPath找到可疑点
def getAbsPostPath(location):
with current_app.app_context():
abspath=os.path.join(current_app.config['PAGE_DIR'],location.replace('/',os.sep))+".md"
return abspath
但是这里也没有显式提交。只是多push了一个app_context，也不至于这样吧？
无奈之下查看Flask-SQLAlchemy源码，还好这货只有两个文件，比较少。
有这么一段：
# 0.9 and later
if hasattr(app, 'teardown_appcontext'):
teardown = app.teardown_appcontext
# 0.7 to 0.8
elif hasattr(app, 'teardown_request'):
teardown = app.teardown_request
# Older Flask versions
else:
if app.config['SQLALCHEMY_COMMIT_ON_TEARDOWN']:
raise RuntimeError("Commit on teardown requires Flask >= 0.7")
teardown = app.after_request
@teardown
def shutdown_session(response_or_exc):
if app.config['SQLALCHEMY_COMMIT_ON_TEARDOWN']:
if response_or_exc is None:
self.session.commit()
self.session.remove()
return response_or_exc这下明白了，原理是它监听了app.teardown_appcontext事件，在该事件发生时会调用
self.session.remove()移除session。这样一来把这一行注释掉，直接使用config模块就解决问题了
def getAbsPostPath(location):
# with current_app.app_context():
abspath=os.path.join(config.PAGE_DIR,location.replace('/',os.sep))+".md"
但同时看到了这个选项SQLALCHEMY_COMMIT_ON_TEARDOWN，是不是Flask-SQLAlchemy可以配置请求执行完逻辑之后自动提交，而不用我们每次都手动调用session.commit()?通过源码看答案是肯定的。
但是好奇的我还是google之，然后在github上看到了这样几段有趣的讨论：先贴地址
https://github.com/mitsuhiko/...
https://github.com/mitsuhiko/...
https://github.com/rosariomgo...
然后在官网看到这样一段：
Consider SQLALCHEMY_COMMIT_ON_TEARDOWN harmful and remove from docs.
什么？考虑移除这一特性？
刚刚知道这么方便的特性，准备用来着，就要被移除？更何况源码中也没有提示要移除啊。
其实是这样的，作者准备在3.0版本移除SQLALCHEMY_COMMIT_ON_TEARDOWN这一特性，目前自2.1以后从文档中移除了相关介绍。
为什么？接下来总结下大神们的探讨。
mattupstate commented on 31 Jan 2015： I'd guess that the reason is due
to the teardown_appcontext callback carrying a bug that, even if you
catch an exception during the app context, the response_or_exc will
never be None. In other words, teardown_appcontext suffers from a
general Python exception handling bug.
这位mattupstate说teardown_appcontext回调存在一个bug，就是即使你正确地捕获了所有的bug，但是回调函数的第一个参数response_or_exc仍然不会为None。这一点令人费解。于是我试验了一发，包括没有bug的情形，主动抛出并捕获的情形，以及after_request中捕获并抛出的情形，都发现response_or_exc为None，没有重现他所说的。why?好想知道为什么。猜测可能是我Python版本，Flask版本的关系？继续看吧
immunda commented on 3 Feb 2015 Sorry for the silence on this. Yep,
that's the motivation, moving away from the (flawed) magic. I'm
waiting to deprecate it entirely (3.0), because there's plans to
introduce a more explicit transaction decorator first.
我去，连Flask-SQLAlchemy作者都支持这一观点，好吧，虽然我没有重现该问题，但是还是就这么认为吧，不用这个特性了。但是还是好奇地看了一下其他的观点。
原来实际上问题是这样的，见https://github.com/mitsuhiko/...
先贴上FLask-SQLAlchemy那部分代码：
@teardown
def shutdown_session(response_or_exc):
if app.config['SQLALCHEMY_COMMIT_ON_TEARDOWN']:
if response_or_exc is None:
self.session.commit()
self.session.remove()
return response_or_exc如果在app.teardown_request中或者在self.session.commit()时发生异常，而这个异常在这里并没有被捕获，那么self.session.remove()也就没有执行，那么这就会影响到下一个请求，下一个请求获取到的session其实是上一个带回滚状态的session，从而导致请求没有按预期效果执行而失败。至此问题算明白了。并不是mattupstate这哥们形容的那样。那么这应该是flask实现机制导致的吧。继续挖。
https://github.com/pallets/fl...
http://stackoverflow.com/ques...
这哥们garaden给Flask提交了代码合并请求，关键部分如下
+ def wrap_teardown_func(teardown_func):
+ @wraps(teardown_func)
+ def log_teardown_error(*args, **kwargs):
+ try:
+ teardown_func(*args, **kwargs)
+ except Exception as exc:
+ app.logger.exception(exc)
+ return log_teardown_error
+
+ if app.teardown_request_funcs:
+ for bp, func_list in app.teardown_request_funcs.items():
+ for i, func in enumerate(func_list):
+ app.teardown_request_funcs[bp][i] = wrap_teardown_func(func)
+ if app.teardown_appcontext_funcs:
+ for i, func in enumerate(app.teardown_appcontext_funcs):
+ app.teardown_appcontext_funcs[i] = wrap_teardown_func(func)如果合并了这部分代码之后，那么以后注册app.teardown_request和app.teardown_appcontext，时异常将会自动被捕获。这在https://github.com/pallets/fl...可以看到新版本Flask已经合并了这部分代码，不存在该问题了。
后面讨论看到
Recently PR pallets/flask#1822 got merged into Flask. Will this maybe
change the fact whether SQLALCHEMY_COMMIT_ON_TEARDOWN will still be
removed in future?
但这对于解决FLask-SQLAlchemy中的问题好像还是没有帮助？是不是我理解错了？如果session.commit发生异常，session.remove这样还是不会执行?
后面看了https://github.com/pallets/fl...中的代码，优化了application context从栈中pop的逻辑，这次的代码提交确保了tear_down回调处理发生异常时不会导致application context无法从栈中弹出而影响后续请求。这下大致明白了。Flask-SQLAlchemy中的db.session依赖于Application Context,所以如果这次Flask能确保无论如何最后会正确弹出application context，那么db.session也随之销毁了，那就不存在后续的影响了。但是，最后这句话我也不敢保证，只能是猜想。
所以，言归正传，如果不用SQLALCHEMY_COMMIT_ON_TEARDOWN这一特性，那么我们怎么确保每次自动提交session呢？
第一种：不是自动，全手动模式commit()，看讨论还是有很多人喜欢这种方式的，不过我讨厌每次都调用commit()
第二种：在after_request中进行提交commit，在teardown_request进行remove
虽说Flask已经修正不需要捕获也可以，但是为了编码的优雅(暂时找不到好点的词)，还是在dbsession_clean中进行了异常捕获。
@app.after_request
def after_clean(resp,*args,**kwargs):
db.session.commit()
return resp
@app.teardown_request
def dbsession_clean(exception=None):
try:
db.session.remove()
finally:
pass第三种：使用自定义装饰器
def route(app_or_sub,rule,**options):
def decorator(f):
@wraps(f)
def decorated_view(*args,**kwargs):
res=f(*args,**kwargs)
db.session.commit()
return res
endpoint = options.pop('endpoint', None)
app_or_sub.add_url_rule(rule, endpoint, decorated_view, **options)
return decorated_view
return decorator