sessionmaker()是一家工厂，它在那里鼓励
Session在一个地方放置用于创建新对象的配置选项。它是可选的，因为您可以
Session(bind=engine,expire_on_commit=False)随时随地调用一个new
Session，除了它冗长而冗长，而且我想阻止小规模的“助手”的泛滥，每个小助手都在某些新版本中解决了这种冗余的问题。和更令人困惑的方式。
因此
sessionmaker()，只有一种工具可以帮助您
Session在需要时创建对象。
下一部分。我认为问题在于，
Session()在各个点上制作一个新的文件与一直使用一个新文件之间有什么区别。答案不是很多。
Session是所有放入其中的对象的容器，然后它还会跟踪未完成的事务。现在，您调用
rollback()或
commit()，事务结束，并且
Session与数据库没有连接，直到再次调用它发出SQL。它提供给映射对象的链接是弱引用，前提是这些对象可以清除未决的更改，因此即使在这种情况
Session下，当您的应用程序丢失对映射对象的所有引用时，will也会将自身清空为全新状态。如果保留其默认值
"expire_on_commit"设置，则所有对象在提交后都将过期。如果该消息
Session停留了五到二十分钟，并且下次您使用它时数据库中的所有事情都发生了变化，那么即使您将这些对象一直放在内存中，它也会在您下次访问这些对象时加载所有全新状态。二十分钟。
在Web应用程序中，我们通常会说，嘿，为什么不
Session针对每个请求创建一个全新的商标，而不是一遍又一遍地使用相同的商标。这种做法可确保新请求开始“干净”。如果先前请求中的某些对象尚未被垃圾回收，并且如果您已关闭
"expire_on_commit"，则先前请求中的某些状态可能仍在徘徊，该状态甚至可能已经很旧了。如果您小心翼翼地保持
expire_on_commit打开状态，并明确地致电
commit()或
rollback()在请求结束时这样做，那很好，但是如果您以全新的开头
Session，那么您根本就没有问题。因此，以一个新的请求开始每个请求的想法
Session实际上，这是确保重新开始并使其使用
expire_on_commit非常可选的最简单方法，因为对于
commit()在一系列操作中间调用的操作，此标志可能会导致大量额外的SQL
。不知道这是否能回答您的问题。
下一轮是您提到的有关线程的内容。如果您的应用程序是多线程的，我们建议确保
Session正在使用的内容是…某物的本地性。
scoped_session()默认情况下，使其成为当前线程的本地对象。在Web应用程序中，本地请求实际上甚至更好。Flask-
SQLAlchemy实际上将自定义“作用域函数”发送到，
scoped_session()以便您获得请求范围的会话。一般的Pyramid应用程序会将会话粘贴到“请求”注册表中。当使用这样的方案时，“在请求开始时创建新的会话”的想法仍然看起来像是使事情保持正直的最直接的方法。
