當讀正式SQLAlchemy的文檔,我發現下面的例子:爲什麼在SQLAlchemy中不鼓勵這種模式?
### this is the **wrong way to do it** ###
class ThingOne(object):
def go(self):
session = Session()
try:
session.query(FooBar).update({"x": 5})
session.commit()
except:
session.rollback()
raise
class ThingTwo(object):
def go(self):
session = Session()
try:
session.query(Widget).update({"q": 18})
session.commit()
except:
session.rollback()
raise
def run_my_program():
ThingOne().go()
ThingTwo().go()
我真的不理解這個模式的弊端。其實我可以想到一個主要的優點:在多線程環境中,這種模式可以確保每個會話實例都是實際使用它的函數的局部變量。
有人能通過給上面的例子給出一些潛在的缺點來啓發我嗎?謝謝。
編輯:作爲多線程上下文中優點的示例。如果我們有一個Web應用程序服務器類在這裏:
class WebApp:
def update(self, **kwargs):
session = Session()
try:...
這裏,頁處理器update
都有自己的本地變量session
,所以無論多少線程運行,它總是安全的。相反,使用另一層功能來包含session
將在這種情況下引入更復雜的方式
你爲什麼不引用[文檔中提出的更好的解決方案以及給出的原因](http://docs.sqlalchemy.org/en/latest/orm/session_basics.html#when-do-i -construct-A-會話時-DO-提交 - 它和當-DO-近距它)。 –
@IljaEverilä我沒有引用'Do'的例子,因爲它只顯示了一個完全相反的解決方案。所以我認爲引用一方會足以說明這個問題。即使引用了它,它仍然不清楚它給你帶來的好處。這只是一個抽象的原則來區分顧慮。但在我的情況下,我需要它絕對是線程安全的,最好不會引入另一層複雜性。 –
@IljaEverilä爲什麼downvote我的問題?我試圖闡明一個不同的觀點。這不是對我們的知識庫做出的貢獻,以便更好地理解該做什麼和不該做什麼嗎? –