最近使用到flask的sqlalchemy，因为flask对sqlalchemy做了一些封装，加上自己本身对sqlalchemy也不熟悉，用法上走了很多弯路。
因为没时间去研究sqlalchemy的源码，所以只能简单的测试下用法。
1、flask-sqlalchemy是线程安全的
2、每次查询完以后，记得commit，不然会占用连接池
我在本地做了个简单的测试，如果单次查询请求完，不commit的话，连续请求几次，再发起request就没有响应了，推测是数据库连接池没释放，被占用。导致请求数据库挂起，从而导致没有response。
每次请求完，直接commit，可以解决此问题。
def queryLast(cls):
try:
ret = db.session.query(cls).order_by(cls.version.desc()).first()
#db.session.expunge(ret)
db.session.commit()
except:
db.session.rollback()
ret = None
return ret
3、但是，如果Commit后，查询结果可能会从缓存中清掉，如果再使用查询结果的对象，还会再次建立连接查询。所以还会出现上述连接池耗尽的问题。
从下图标黄的日志可以看出，commit后，使用返回的查询结果时，又执行了一次查询任务，并返回结果，my god！
2019-12-10 12:31:21,650 INFO sqlalchemy.engine.base.Engine BEGIN (implicit)
2019-12-10 12:31:21,651 INFO sqlalchemy.engine.base.Engine SELECT appversion.id AS appversion_id, appversion.version AS appversion_version, appversion.`appUrl` AS `appversion_appUrl`, appversion.des AS appversion_des, appversion.`createTime` AS `appversion_createTime`, appversion.`lastModiftyTime` AS `appversion_lastModiftyTime`, appversion.type AS appversion_type
FROM appversion ORDER BY appversion.version DESC
LIMIT %s
2019-12-10 12:31:21,651 INFO sqlalchemy.engine.base.Engine (1,)
2019-12-10 12:31:21,661 INFO sqlalchemy.engine.base.Engine COMMIT
2019-12-10 12:31:21,680 INFO sqlalchemy.engine.base.Engine BEGIN (implicit)
2019-12-10 12:31:21,681 INFO sqlalchemy.engine.base.Engine SELECT appversion.id AS appversion_id, appversion.version AS appversion_version, appversion.`appUrl` AS `appversion_appUrl`, appversion.des AS appversion_des, appversion.`createTime` AS `appversion_createTime`, appversion.`lastModiftyTime` AS `appversion_lastModiftyTime`, appversion.type AS appversion_type
FROM appversion
WHERE appversion.id = %s
2019-12-10 12:31:21,681 INFO sqlalchemy.engine.base.Engine (1,)4、但有时候（可能是时间略长些）commit后，再使用查询结果的对象，可能会出现报错：Instance <User at 0x32768d0> is not bound to a Session
此种情况可能是因为绑定的session已经被回收，导致无法再进行查询，所以出错。
5、综上所述，为安全起见，需要在查询结果后，加上 db.session.expunge(ret)，断开查询结果与session的关系。让它成为一个本地实体，不会从缓存中清除，使用时候，就不会再查询。
6、但测试时候发现一个奇怪的问题，另外一个获取user的接口，和上面的代码几乎没什么区别，居然会自动rollback，这个让我百思不得其解。
我的逻辑是取到查询结果（即用户）后，判断用户的状态字段是否为1，如果为1，就修改用户属性，然后commit，如果不是1，就不做操作，也没有调用rollback。
但是我测试时候发现，如果不是1的时候，它会自动rollback。
或许这是sqlalchemy的高级功能？
7、总结：
1、sqlalchemy的对象实体（model），和session建立了联系，你get、set这些model的时候，就算已经commit，也会重新自动和数据库建立连接（get的时候会重新select、set的时候会重新建立连接，等待你提交，如果你不提交，这个连接一直存在，最终会耗尽。），所以要谨慎使用model的字段，除非你确实明白自己在做什么，会发生什么。
2、使用db.session.expunge会切断实体和session的关系。这个是个不错的用法。
3、但我还是强烈建议自己再搞一套model，来做业务层逻辑。sqlalchemy的对象实体仅用来做数据库的操作。这样会避免很多时候，连接不小心没释放的坑。