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

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions