|
| 1 | +# CodeIndex DB Compatibility |
| 2 | + |
| 3 | +> **[日本語版はこちら / Japanese version](#codeindex-db-compatibility日本語)** |
| 4 | +
|
| 5 | +This document defines the compatibility contract between `cdidx` binaries and |
| 6 | +the local SQLite database under `.cdidx/codeindex.db`. |
| 7 | + |
| 8 | +## Supported Readers |
| 9 | + |
| 10 | +The public compatibility boundary is the `cdidx` CLI and MCP server reading a |
| 11 | +database created by a released `cdidx` binary. The SQLite schema is an internal |
| 12 | +storage format, not a public API. |
| 13 | + |
| 14 | +Within a supported release line, newer binaries must read older databases and |
| 15 | +degrade optional features explicitly when stored readiness metadata is missing |
| 16 | +or stale. Older binaries may read newer databases only when the newer database |
| 17 | +does not advertise unknown readiness or contract stamps. If an older binary sees |
| 18 | +unknown persisted contract stamps, it must degrade loudly in `status` output and |
| 19 | +must refuse writes that could silently discard newer data. |
| 20 | + |
| 21 | +## Schema and Readiness Stamps |
| 22 | + |
| 23 | +`PRAGMA user_version` is a readiness bitmap, not a linear migration number: |
| 24 | + |
| 25 | +| Bit | Field | Meaning | |
| 26 | +|---|---|---| |
| 27 | +| `1` | `graph_table_available` / graph readiness | `symbol_references` has been fully populated for graph queries. | |
| 28 | +| `2` | `issues_table_available` / issue readiness | `file_issues` has been populated for validation results. | |
| 29 | +| `4` | `fold_ready` | Folded-name columns are current for Unicode-aware exact-name matching. | |
| 30 | + |
| 31 | +Additional per-feature contract versions live in `codeindex_meta`, including |
| 32 | +folded-key metadata, C# symbol-name and metadata-target versions, SQL graph |
| 33 | +contract stamps, hotspot-family readiness, index writer version, indexed HEAD |
| 34 | +metadata, unknown-extension counts, filesystem case-sensitivity, MAC profile, |
| 35 | +and DB/WAL/status diagnostics. These stamps let readers distinguish a feature |
| 36 | +that is absent, stale, or newer than the running binary. |
| 37 | + |
| 38 | +## Version Skew Behavior |
| 39 | + |
| 40 | +Use `cdidx status --json` or `cdidx status --check --json` before relying on a |
| 41 | +database across binary upgrades or downgrades. |
| 42 | + |
| 43 | +| Scenario | Expected behavior | Operator action | |
| 44 | +|---|---|---| |
| 45 | +| New binary reads an older DB | Queries continue where possible. Missing readiness fields report degraded status and include remediation strings. | Run the recommended maintenance command from `status`, usually `cdidx backfill-fold` or `cdidx index <projectPath> --rebuild`. | |
| 46 | +| Same binary reads its own DB | `status --check --json` reports `index_matches_workspace: true` when file content and HEAD metadata match. | No rebuild required. | |
| 47 | +| Older binary reads a newer DB | `index_newer_than_reader` becomes `true` when unknown readiness bits or contract stamps exceed the binary's maximum. Mutating commands refuse to write unsafe newer DBs. | Use the newer `cdidx` binary that wrote the DB, or rebuild the index with the older binary only after accepting loss of newer feature data. | |
| 48 | +| Read-only CI artifact | Query commands may use `--read-only` / `--immutable`. Mutating commands reject read-only DBs. | Pin the `cdidx` binary version with the DB artifact when possible. | |
| 49 | + |
| 50 | +## Rebuild Requirements |
| 51 | + |
| 52 | +Additive schema changes should be readable by newer binaries without requiring a |
| 53 | +full rebuild. Prefer in-place maintenance for derived data, such as |
| 54 | +`cdidx backfill-fold`, when a feature can be refreshed from existing rows. |
| 55 | + |
| 56 | +A rebuild is required when: |
| 57 | + |
| 58 | +- `status` recommends `cdidx index <projectPath> --rebuild`; |
| 59 | +- the workspace and DB are intentionally being reset to an older binary version; |
| 60 | +- the database is corrupt or fails `cdidx db --integrity-check`; |
| 61 | +- a release note explicitly calls out a breaking storage change. |
| 62 | + |
| 63 | +Breaking DB changes must be rare and must document the minimum binary version, |
| 64 | +the downgrade behavior, and the rebuild path in release notes. |
| 65 | + |
| 66 | +## CodeIndex DB Compatibility(日本語) |
| 67 | + |
| 68 | +この文書は、`cdidx` binary と `.cdidx/codeindex.db` のローカル SQLite database |
| 69 | +の互換性契約を定義します。 |
| 70 | + |
| 71 | +## 対応する reader |
| 72 | + |
| 73 | +公開される互換性境界は、release 済み `cdidx` binary が作成した database を |
| 74 | +`cdidx` CLI / MCP server が読むことです。SQLite schema は内部 storage format |
| 75 | +であり、公開 API ではありません。 |
| 76 | + |
| 77 | +対応 release line 内では、新しい binary は古い database を読み、保存済みの |
| 78 | +readiness metadata が不足または stale の場合は optional feature を明示的に |
| 79 | +degrade しなければなりません。古い binary が新しい database を読めるのは、 |
| 80 | +その database が未知の readiness / contract stamp を示していない場合だけです。 |
| 81 | +未知の永続 contract stamp を見た古い binary は `status` で明示的に degrade を |
| 82 | +報告し、新しい data を黙って破棄しうる write を拒否します。 |
| 83 | + |
| 84 | +## Schema と readiness stamp |
| 85 | + |
| 86 | +`PRAGMA user_version` は線形 migration number ではなく readiness bitmap です。 |
| 87 | + |
| 88 | +| Bit | Field | 意味 | |
| 89 | +|---|---|---| |
| 90 | +| `1` | `graph_table_available` / graph readiness | graph query 用の `symbol_references` が完全に作成済み。 | |
| 91 | +| `2` | `issues_table_available` / issue readiness | validation result 用の `file_issues` が作成済み。 | |
| 92 | +| `4` | `fold_ready` | Unicode-aware exact-name matching 用の folded-name column が最新。 | |
| 93 | + |
| 94 | +追加の feature contract version は `codeindex_meta` に保存されます。これには |
| 95 | +folded-key metadata、C# symbol-name / metadata-target version、SQL graph |
| 96 | +contract stamp、hotspot-family readiness、index writer version、indexed HEAD |
| 97 | +metadata、unknown-extension count、filesystem case-sensitivity、MAC profile、 |
| 98 | +DB/WAL/status diagnostics が含まれます。reader はこれらの stamp により、feature |
| 99 | +が存在しないのか、stale なのか、実行中 binary より新しいのかを判別できます。 |
| 100 | + |
| 101 | +## Version skew 時の動作 |
| 102 | + |
| 103 | +binary upgrade / downgrade をまたいで database を使う前に、 |
| 104 | +`cdidx status --json` または `cdidx status --check --json` を確認してください。 |
| 105 | + |
| 106 | +| 状況 | 期待される動作 | 操作者の対応 | |
| 107 | +|---|---|---| |
| 108 | +| 新しい binary が古い DB を読む | 可能な query は継続します。不足した readiness field は degraded status と remediation を返します。 | `status` の推奨に従い、通常は `cdidx backfill-fold` または `cdidx index <projectPath> --rebuild` を実行します。 | |
| 109 | +| 同じ binary が自身の DB を読む | file content と HEAD metadata が一致すると `status --check --json` は `index_matches_workspace: true` を返します。 | rebuild は不要です。 | |
| 110 | +| 古い binary が新しい DB を読む | 未知の readiness bit または contract stamp が binary の最大値を超えると `index_newer_than_reader` が `true` になります。mutating command は unsafe な write を拒否します。 | その DB を書いた新しい `cdidx` binary を使うか、新しい feature data が失われることを受け入れて古い binary で index を作り直します。 | |
| 111 | +| read-only CI artifact | query command は `--read-only` / `--immutable` を利用できます。mutating command は read-only DB を拒否します。 | 可能なら DB artifact と `cdidx` binary version を一緒に pin します。 | |
| 112 | + |
| 113 | +## Rebuild が必要な場合 |
| 114 | + |
| 115 | +Additive schema change は、full rebuild を要求せずに新しい binary で読めるべきです。 |
| 116 | +既存 row から再生成できる derived data は、`cdidx backfill-fold` のような |
| 117 | +in-place maintenance を優先します。 |
| 118 | + |
| 119 | +rebuild が必要なのは次の場合です。 |
| 120 | + |
| 121 | +- `status` が `cdidx index <projectPath> --rebuild` を推奨している; |
| 122 | +- workspace と DB を意図的に古い binary version へ戻す; |
| 123 | +- database が壊れている、または `cdidx db --integrity-check` に失敗する; |
| 124 | +- release note が breaking storage change を明示している。 |
| 125 | + |
| 126 | +Breaking DB change は稀であるべきで、minimum binary version、downgrade behavior、 |
| 127 | +rebuild path を release note に記載しなければなりません。 |
0 commit comments