爲什麼在請求發出後不能使用flask.g？

根據the Flask 0.12 docs：爲什麼在請求發出後不能使用flask.g？

flask.g

......從Flask 0.10這被存儲在應用程序上下文和不再這意味着它請求上下文開始變得可用如果只應用上下文綁定而不是請求。

據我所知，當一個請求到來時，如果沒有一個應用程序上下文將被創建。因此，在請求到來之後，請不要flask.g可用，因爲請求確保存在應用程序上下文？

作爲一個bouns問題：爲什麼我應該在g而不是request上存儲數據庫連接？我知道創建應用程序上下文比創建請求上下文更「昂貴」，但當請求到來時，無論如何都會創建請求上下文。

來源

2017-07-18 Sun Qingyao

措辭有點尷尬。 g對象在請求以及期間可用。請求上下文嵌套在應用程序上下文中。

您應該在g對象中存儲數據庫連接，因爲即使沒有請求（例如flask shell命令和任何custom command-line commands），它也將可用*。例如，在初始化數據庫時，您將需要這個。

接下來，有些高級用例可能需要創建一個'內部'請求，在Flask應用上調用另一條路由，就好像它來自外部。此嵌套請求將重新使用現有的應用程序上下文。

沒有應用程序上下文，永遠不會有請求上下文。

來源

2017-07-18 08:09:15

謝謝先生，這很有道理。但是，當請求到來並且應用程序上下文已經存在時，就會出現問題：從[源代碼]（https://github.com/pallets/flask/blob/1949c4a9abc174bf29620f6dd8ceab9ed3ace2eb/flask/ctx.py#L230）當'app_ctx爲None或app_ctx.app！= self.app'時，現有應用程序上下文將被重用，但文檔指出應用程序上下文[不會在請求之間共享]（http://flask.pocoo.org/ docs/0.12/appcontext /＃上下文的位置）... –

該代碼確保正確的請求上下文與正確的應用程序上下文配對，僅此而已。當請求進入時，app context * always *已經存在。該代碼所做的是確保該請求的應用上下文位於堆棧頂部，以便爲該請求運行的所有代碼都有正確的'flask.g'對象。 –

僅適用於多個應用程序上下文處於活動狀態時。 –

flask.g被綁定到當前請求的會話。這意味着對於不同的請求你有不同的g。例如，我存儲以g對象的用戶爲它更容易獲得（這不是很好，但快速訪問和易於使用）

來源

2017-07-18 08:10:51 alexcleac

從Flaskdocumentation回答獎金問題：

例如， request變量是與當前請求相關聯的請求對象，而g是與當前應用上下文相關聯的通用變量。

來源

2017-07-18 08:31:39 kemis

爲什麼在請求發出後不能使用flask.g？

回答

相關問題