# search-parity

Regression check for `POST /api/metadata/search` against a running meta-core.
Since v2.0.0 it reads the merged view from the cache database
(`/meta-core/db-cache/cache.db`), which keeps the v1 `file:<rid>/<field>` layout.

- `parity.py <cache.db>` builds ~230 queries from real records (free text,
  short tokens, key-set and flat filters, exact/contains, multi-filter). It
  computes each query's expected result by brute force: one streaming pass
  over every record, using a port of the Go matchers. Then it diffs that
  against the live API. Any `lost` result means the SQL candidate superset
  dropped a real match.
- `timing.py [cache.db]` times the same query set at limit 100 and 2000.

Run them inside the container. It has python3 and reads the database
read-only:

```bash
docker cp tools/search-parity metacore-app:/tmp/sp
docker exec metacore-app python3 -u /tmp/sp/parity.py /meta-core/db-cache/cache.db
docker exec metacore-app python3 -u /tmp/sp/timing.py
```

The reference pass takes ~10 min at 169k records. Records written while it
runs can show up as `extra` at a limit-2000 boundary; check their UUIDv7 time
before treating a diff as real.

History: these tools gated the 2026-10 Redis → SQLite cut-over. Results:
0/217 diffs on v1.1.0, and 232/234 on v1.2.0, where the 2 diffs were writes
made during the run. See
`docs/project-architecture/metacore-storage-engine.md` in the meta-root.