opensource/mateclaw
2
0
Fork 0
mirror of https://gitee.com/mateos/mateclaw.git synced 2026-09-13 03:13:41 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

fix(llm): purge mate_model_config tombstones (V118)

Browse Source
This commit is contained in:
matevip 2026-05-20 10:14:19 +08:00
parent a6b5e3b515
commit 58c53687e5
2 changed files with 30 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
mateclaw-server/src/main/resources/db/migration/h2/V118__purge_model_config_tombstones.sql Normal file
View File

@ -0,0 +1,15 @@
-- V118: Purge residual deleted=1 rows from mate_model_config.
--
-- V20 retired soft-delete project-wide and physically deleted every deleted=1
-- row that existed at that point. V81 then re-introduced an isolated tombstone
-- on id=1000000172 (the bogus 'qwen3-plus' catalog entry) — keeping the row
-- around as a logical audit trail. The runtime never re-uses ids and treats
-- `deleted` as a vestige now that @TableLogic is gone, so a tombstoned row
-- has no value beyond leaking into LambdaQueryWrapper queries that don't
-- explicitly filter `deleted=0`.
--
-- The validateModel uniqueness check fix in #173 plugged one such leak; this
-- migration eliminates the underlying class of bug by aligning mate_model_config
-- with the V20 hard-delete posture. Idempotent: a no-op on databases without
-- tombstones.
DELETE FROM mate_model_config WHERE deleted = 1;

15
mateclaw-server/src/main/resources/db/migration/mysql/V118__purge_model_config_tombstones.sql Normal file
View File

@ -0,0 +1,15 @@
-- V118: Purge residual deleted=1 rows from mate_model_config.
--
-- V20 retired soft-delete project-wide and physically deleted every deleted=1
-- row that existed at that point. V81 then re-introduced an isolated tombstone
-- on id=1000000172 (the bogus 'qwen3-plus' catalog entry) -- keeping the row
-- around as a logical audit trail. The runtime never re-uses ids and treats
-- `deleted` as a vestige now that @TableLogic is gone, so a tombstoned row
-- has no value beyond leaking into LambdaQueryWrapper queries that don't
-- explicitly filter `deleted=0`.
--
-- The validateModel uniqueness check fix in #173 plugged one such leak; this
-- migration eliminates the underlying class of bug by aligning mate_model_config
-- with the V20 hard-delete posture. Idempotent: a no-op on databases without
-- tombstones.
DELETE FROM mate_model_config WHERE deleted = 1;