Skip to content

Schema-v2 migration hazard: Neo4j code property must be derived from source spans, not a model field #176

Description

@rahlk

Heads-up filed from codellm-devkit/codeanalyzer-python#104 (propagation sweep).

When this analyzer migrates to canonical schema v2, the per-node code field moves off JCallable/JType (source is stored once per compilation unit, sliced by byte spans). GraphProjector currently reads c.getCode() directly (e.g. around the callable/type row builders) and Schema.java builds the j_code_fts fulltext index over c.code/c.docstring.

If the migration drops the model field without changing the projector, every :JCallable/:JType node silently loses code — the fulltext index goes dead and any SDK RETURN c.code query returns null. This exact failure shipped in codeanalyzer-python 1.0.0/1.0.1 and was fixed in 1.0.2 by deriving code at projection time from the owning module's source and the node's byte span (codellm-devkit/codeanalyzer-python#105).

Action for the v2 migration checklist: keep the graph's code property and derive it at projection time (span slice), or explicitly drop it from the SchemaCatalog + j_code_fts and bump the Neo4j SCHEMA_VERSION. Declared-but-null is the one option that breaks consumers silently.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions