After #65 (dual TS twin labels, graph schema 1.1.0), the bolt writer's incremental path only upserts nodes of modules whose content_hash changed (src/build/neo4j/bolt.ts, changed-module diff). Pushing an upgraded analyzer against a database written by schema 1.0.0 therefore stamps twins on changed modules (and shared nodes) only, while the always-upserted :Application.schema_version already advertises 1.1.0 — so MATCH (n:TSCallable) undercounts versus MATCH (n:Callable) until every module churns or a full run happens.
Options (from the branch review):
- one-time backfill when the DB's stamped version < producer version (e.g. per label
MATCH (n:Callable) SET n:TSCallable), or
- force a full upsert when the stored
schema_version differs from the producer's.
Stage 2 of the epic (bare-label drop + TS_ rel types) will hit this same seam harder, so this should land before it.
Part of #64 (surfaced by the #65 branch review).
Fresh projections, the cypher snapshot path, and full runs are unaffected.
After #65 (dual TS twin labels, graph schema 1.1.0), the bolt writer's incremental path only upserts nodes of modules whose
content_hashchanged (src/build/neo4j/bolt.ts, changed-module diff). Pushing an upgraded analyzer against a database written by schema 1.0.0 therefore stamps twins on changed modules (and shared nodes) only, while the always-upserted:Application.schema_versionalready advertises 1.1.0 — soMATCH (n:TSCallable)undercounts versusMATCH (n:Callable)until every module churns or a full run happens.Options (from the branch review):
MATCH (n:Callable) SET n:TSCallable), orschema_versiondiffers from the producer's.Stage 2 of the epic (bare-label drop +
TS_rel types) will hit this same seam harder, so this should land before it.Part of #64 (surfaced by the #65 branch review).
Fresh projections, the cypher snapshot path, and full runs are unaffected.