Day 18 : 現在才看懂原來我真的有建SQL...

2025 iThome 鐵人賽

DAY 18

自我挑戰組

第一次團體專題系列第 18 篇

17th鐵人賽

s35indy

2025-10-02 23:33:50

58 瀏覽

分享至

今天發生一個大烏龍 , 原來我一直誤會我沒有建SQL , 但其實每次程式運行的時候都會RESET資料,把資料用.py的檔案寫入 , 還特別問了GPT為何CODEX這樣設計的原因 , GPT的講解真的超細節 , 我這個小白終於了解了

表一：SQLite 與 Demo 資料初始化問題、原因與解法

此表格整理了專案在 SQLite 資料庫和示範資料（Demo Data）初始化過程中遇到的難點及其建議的解決方案。

問題點 (Issue)	原因/狀況 (Cause/Status)	解決方式/建議 (Solution/Suggestion)
找不到正確的 SQLite 資料檔	開發者誤認 `database.sqlite`（空檔）或 `backend/data/mvp.sql`（純文字 SQL 腳本）為使用檔。後端實際使用的是 `backend/data/mvp.sqlite3`。	確認 Flask 真正使用的資料庫是 `backend/data/mvp.sqlite3`。
缺少 9 月份交易資料	啟動時 `ensure_demo_data()` 只建立 1 月份起的示範交易模板。雖然 `_seed_member_history()` 定義了 9 月 50 筆交易，但最初沒有被呼叫。	需要讓 `_seed_member_history()` 在初始化時確實執行。後來已整合進 `ensure_demo_data()` 流程，保證每個 persona 都有 9 月份交易。
Demo 資料在啟動後被覆蓋	`backend/data/mvp.sql` 裡的 9 月資料，一旦應用程式重新啟動並執行 `_reset_seed_profiles()`，這些紀錄就會被刪除。	建議將交易資料寫在 `seed_transactions.sql`，每次啟動時清掉 DB 後再匯入固定 SQL，以避免隨機生成。
會員列表/Dashboard 未顯示照片	頁面依賴 `member_profiles.first_image_filename`，只有「已存在 member_id」時才會寫入。若無對應 `member_profiles` 或空的 `persona` 預留槽位，頁面會顯示「尚未留存首次辨識影像」。	須在 `member_profiles` 預留一筆 `member_id = NULL` 的槽位 (`staging-slot-01`)。新會員上傳臉孔時，`_claim_unassigned_profile()` 就能綁定此槽位並寫入影像檔名。
Amazon Rekognition 與 DB 資料不一致	如果 DB 不重置，但 Amazon Rekognition collection 重置，會造成會員臉孔與資料庫對不上。	建議用環境變數控制 (`DB_RESET=1`, `REKOG_RESET=1`)，確保 DB 與 Amazon Rekognition 必須同步 `reset`，以保持兩邊同步。

表二：程式化資料種子 (Seeding) 設計考量

此表格分析了專案中為什麼要使用 Python 函式（例如 ensure_demo_data(), _seed_member_history()）來生成資料，而不是單純依賴靜態 SQL 檔案，以及相關的職責分離設計。

設計考量/機制 (Design Consideration/Mechanism)	目的/優點 (Goal/Advantage)	來源 (Source)
程式化生成種子資料 (Code-based Seeding)	保持資料庫初始化的可重現性。保證每次啟動都能得到乾淨、一致的資料狀態，不用擔心 SQL 檔案被測試污染或資料殘留。
支援動態生成資料	用 Python 生成（如 `_seed_member_history()` 隨機生成 9 月交易）可以引入邏輯，例如隨機消費時間、商品類別分布等，使測試數據比死板的 SQL dump 更靈活、更具「真實感」。
簡化部署與版本控制	GitHub repo 只需維護 `.py` 檔案。增加可移植性：未來換到其他資料庫（如 MySQL、Postgres）時，資料生成邏輯仍可重用。
最初將 `_seed_member_history()` 與 `ensure_demo_data()` 分離	職責分離：`ensure_demo_data()` 負責最小可運作的 demo，而 `_seed_member_history()` 負責補充更完整、更真實的樣本歷史（如 9 月 50 筆隨機交易）。
後來整合	為了滿足 Demo 場景對完整歷史資料的需求，確保每個 persona 都自動被補齊 9 月份的交易，這是因為需求明確化所導致的演進過程。

表三：專案開發與除錯紀錄

此表格整理了專案在開發過程（例如 Flask、Python 環境、Git 操作）中遇到的具體技術問題和解決方式。

問題 (Issue)	錯誤訊息/狀況 (Error Message/Status)	解決方式 (Solution)
Gemini API 超時	錯誤訊息：`504 The request timed out`。	檢查 API 配額；在 Flask 呼叫時加上 `timeout` 參數。
Python 變數定義缺失 (OS/ADS_DIR)	`NameError: name 'os' is not defined`；`NameError: name 'ADS_DIR' is not defined`。	忘記 `import os`。 `ADS_DIR` 未在 `app.config` 設定前被宣告。需要在檔案開頭補上 `import os`，並在設定前宣告 `ADS_DIR` 變數。
Flask 路由函式重複	`AssertionError: View function mapping is overwriting an existing endpoint function: latest_ad_stream`。	Flask 同一個 endpoint 名稱被定義了兩次。需刪除舊的或改名（例如 `latest_ad_stream_v2`）。
Git 分支合併出錯	分支測試 OK，但合併（merge）到 `main` 後出現錯誤，原因可能是 `main` 有舊程式殘留。	如果要讓 `main` 完全等於分支，使用 `git reset --hard your-branch`，然後 `git push origin main --force`。
外部 500 內部伺服器錯誤	上傳路徑 `/upload_face` 回傳 500。Log 顯示 `TypeError: __init__() got an unexpected keyword argument 'scenario'`。	`PurchaseInsights` class 在定義中沒有 `scenario` 參數。解決方法為在 class 定義中加上 `scenario` 欄位，或在呼叫時移除該參數。