Repository navigation
[CRM] 9 个孤儿 __search 列待清理（17.0 收紧搜索伴生列供给条件后遗留） #528
Description
Activity
⚠️ 改判：不要执行本 issue 原建议的--allow-destructive清理。列级验证（同一 worktree、同一 artifact、两个全新库）：
objectstack dev建的库：crm_task34 列，含__searchos migrate plan --database-url <新文件>建的库：33 列，无__search；且 migrate 对自己建的库报 0 destructive
即这 9 个
__search不是孤儿，而是 dev 运行时（pinyin 搜索伴生列）供给并在用的活列；是 migrate CLI 与 dev 运行时的 schema 视图不一致把它们误判成孤儿。按原建议清理会删掉搜索功能的列，下次 dev 启动还可能重建。已上报平台：objectstack-ai/objectstack#3955（含复现表格；顺带报告了全新库立即出现 3 条 relax_unique_index 的建表/漂移不对称）。
本 issue 状态改为：阻塞于上游 #3955，在平台修复前不做任何本地清理动作。
- added a commit that references this issue
on Jul 30, 2026 已重开：本 issue 是被提交信息误关的，结论未变
#542 合并后本 issue 于 2026-07-30 10:04 被自动关闭。这是误关，已重开。
原因
关闭它的不是 PR 描述，而是 commit message：
fba1f4fa（#542 的首个提交）正文第 14 行带着Closes #528。该提交随合并进入main，GitHub 按提交信息执行了自动关闭。改写 #542 描述时我确认过 GitHub 的
closingIssuesReferences字段为 0，据此判断合并不会关闭本 issue——那个字段只反映 PR 描述，不包含提交信息里的关键字，所以判断有误。提交信息在 PR 创建时就已写好，改描述改不到它。结论不变：不要做任何清理
评论区早前的改判仍然成立：
- 那 9 个
__search列不是孤儿，是 dev 运行时（拼音搜索伴生列）供给并在用的活列； - 根因是 migrate CLI 与 dev 运行时的 schema 视图不一致，已上报 objectstack#3955；
- 按原建议执行
os migrate apply --allow-destructive会删掉搜索功能的列。
本 issue 保持打开，阻塞于上游 #3955，在平台修复前不做任何本地清理动作。
已合并的 #542 并不与此矛盾
#542 最终合入的手册（
docs/MAINTENANCE.md§3.1）已经按改判重写：它把 17.0 的__search报告记为已知误报（do not touch until #3955 lands），并给计划复核步骤加了第二道判据（是否运行时伴生列）和取证方法（与同 artifact 新建库对比列清单）。也就是说 main 上的文档立场是正确的，只有这个 issue 的开关状态错了，现已修正。给后续的提醒
若某个 PR 的提交信息里带
Closes/Fixes #N，仅改 PR 描述不足以阻止关闭——需要改写提交信息（force-push），或在合并后手动重开，就像这次一样。- 那 9 个
- added a commit that references this issue
on Aug 5, 2026 rc.2 retest: 孤儿条件在新库上已不存在 —— the cleanup this issue tracks only applies to rc.0-era databases
Retested on
@objectstack/*17.0.0-rc.2 (currentmain), against a freshly created rc.2 DB (isolated dev server, own file, full seed).1. The fresh DB has 5
__searchcolumns, all live (PRAGMA scan):crm_event, crm_opportunity, crm_opportunity_line_item, crm_quote_line_item, crm_task2.
migrate planagainst that DB — while the server is running — reports:✓ Physical schema is in sync with metadata — nothing to migrate.No
__searchcolumn is flagged as a destructive orphan. This is the upstream objectstack#3955 fix landed: the migrate CLI and the dev runtime now agree on search-companion provisioning, so live__searchcolumns are no longer misreported as droppable.(Control that the orphan detector itself still works: a deliberately planted junk column on the same DB was correctly flagged
[drop_column]destructive — so the clean report above is a real verdict, not a silenced check.)What this means for this issue: the "9 orphan
__searchcolumns" recorded here were observed on the rc.0-era upgrade-branch database. On any database created by 17.0, the condition does not arise. The cleanup remains relevant only for databases carried forward from before the fix — and per the earlier rescission in this issue's history, do not run--allow-destructivefrom a state where the CLI can't see the full app set.Recommend either closing as resolved-by-upstream, or re-scoping the title to "legacy DBs only" if any production DB predates rc.1. Reporting rather than closing per this run's test-don't-fix mandate.
Generated by Claude Code
[17.0-rc2验收复核] 结论:已不复现(全新 rc.2 库上孤儿条件不成立;migrate 与 dev 运行时的 schema 视图已一致)
证据:独立 dev server(端口 4091)的全新 rc.2 种子库,better-sqlite3 直查 PRAGMA:
- 89 张表中 74 张带
__search列:69 张为sys_*平台表,CRM 侧 5 张 ——crm_event/crm_opportunity/crm_opportunity_line_item/crm_quote_line_item/crm_task(与今晨复测清单一致)。 - server 运行中执行
os migrate plan→✓ Physical schema is in sync with metadata — nothing to migrate.(Examined 22 managed table(s))—— 没有任何__search被判孤儿。 - 控制组:故意植入
crm_task.zz_a1_probe后 plan 正确报[drop_column]destructive(测毕已删)——干净结论出自活着的检测器,非静默。
即 objectstack#3955(migrate CLI 与 dev 运行时对搜索伴生列供给的视图分歧)已在 rc.2 落地:活的
__search列不再被误报为可删。本单记录的「9 个孤儿」只存在于 rc.0 时代 upgrade 分支的旧库;任何由 17.0 新建的库不会出现该条件。历史评论中的改判(勿对旧库跑--allow-destructive)对 rc.1 之前遗留库依然有效。环境:hotcrm@0899b4f + @objectstack 17.0.0-rc.2
建议:前提已过时建议关闭(如仍有早于 rc.1 的存量库需处置,按
docs/MAINTENANCE.md§3.1 的两道判据走,不必留本单)。
Generated by Claude Code
- 89 张表中 74 张带
Closing as premise-expired, per the assignee's own rc.2 retest and recommendation (2026-08-05 comment): on a fresh rc.2 database the orphan condition does not arise —
os migrate planreports schema in sync, no__searchcolumn flagged, with a planted-junk-column control proving the detector is alive. Upstream objectstack#3955 (migrate CLI vs dev runtime schema-view divergence) has landed.The "9 orphan columns" existed only on the rc.0-era upgrade-branch database. Guidance for any legacy pre-rc.1 database is already codified in
docs/MAINTENANCE.md§3.1 (two-criterion check; never--allow-destructivefrom a state where the CLI can't see the full app set) — no open card needed to carry it.Closure issued by the PM loop (session
session_01NM6o28jmBgsyTRQHutn7LC), citing the assignee's recommendation quoted above; maintainer may veto by reopening.
Generated by Claude Code
现象
os migrate plan报 9 个对象存在数据库里有、元数据中无的__search伴生列（crm_competitor、crm_opportunity_line_item、crm_quote_line_item、crm_task、sys_metadata 等）。不影响功能。择机执行
os migrate apply --allow-destructive清理即可（注意先停服务，参见平台 issue #526）。详见分支
upgrade/objectstack-17的 docs/upgrade-17/test-report.md §4 L2。