Skip to content

v1.4.2

Latest
Latest

Choose a tag to compare

View all tags
@lawrence8358 lawrence8358 released this 10 Nov 13:35
v1.4.2
26d3ee1

Release v1.4.2

發布日期 (Date): 2026-11-10

主要亮點 (Highlights):

  • 修正同時移除欄位與該欄位外鍵時部署失敗（42704 constraint ... does not exist）的問題；42704 錯誤不再一律附上「缺少 extension」的誤導提示。
  • Fixed deployments failing with 42704 constraint ... does not exist when a column and its foreign key are removed together; 42704 errors no longer always carry the misleading "missing extension" hint.

🌟 What's New / 主要更新

🚀 Features / 新功能

*「無 / None」

🛠 Refactoring & Improvements / 重構與效能優化

  • 42704 錯誤提示更精準：原本只要遇到 42704 undefined_object 就附上「通常是缺少 PostgreSQL extension」的提示，但 constraint、index 不存在也屬於 42704。現在只有錯誤訊息為「型別不存在」（type "..." does not exist）時才附上此提示；42883 undefined_function 維持不變。

    EN: More accurate hint for 42704 errors: the "often caused by a missing PostgreSQL extension" hint used to be appended to every 42704 undefined_object error, although missing constraints or indexes also raise 42704. The hint is now added only when the message reports a missing type (type "..." does not exist); 42883 undefined_function is unchanged.

🐛 Bug Fixes / 問題修復

  • 修正同時移除欄位與其外鍵時部署失敗：SQL 定義檔把某欄位連同其外鍵一起移除（例如把 ServiceId + FK_..._ServiceId 換成 ScanTargetId + FK_..._ScanTargetId）時，Table Changes 群組原本先執行 DROP COLUMN 再執行 DROP CONSTRAINT。PostgreSQL 刪除欄位時會自動刪除該欄位上的約束，導致後續 DROP CONSTRAINT 失敗（42704），整個群組回滾。現在 Table Changes 群組的語句順序為：外鍵的 DROP CONSTRAINT（DropForeignKey、RecreateForeignKey 的刪除部分）最前，接著主鍵的 DROP CONSTRAINT（RecreatePrimaryKey 的刪除部分），其餘語句依差異順序在後。規則記錄於 docs/dev-guide-architecture.md，後續新增會刪除約束的變更類型時，須一併放入前置刪除清單。

    EN: Fixed deployments failing when a column is removed together with its foreign key: when a SQL definition removed a column and its foreign key at the same time (e.g. replacing ServiceId + FK_..._ServiceId with ScanTargetId + FK_..._ScanTargetId), the Table Changes group ran DROP COLUMN before DROP CONSTRAINT. PostgreSQL drops a column's constraints automatically, so the subsequent DROP CONSTRAINT failed with 42704 and the whole group rolled back. The Table Changes group now runs foreign-key DROP CONSTRAINT statements first (DropForeignKey and the drop part of RecreateForeignKey), then primary-key DROP CONSTRAINT statements (the drop part of RecreatePrimaryKey), followed by all other statements in diff order. The rule is documented in docs/dev-guide-architecture.md; any future change type that drops a constraint must also go into this pre-drop list.

⚠️ Breaking Changes / 重大變更

*「無 / None」

Assets 4
Loading