fix(mybatis): XML mapper READS/WRITES edges not matching Function nodes (2793 parsed → 68 written) #890
Description
Problem
When indexing a large Java codebase with 475 MyBatis XML mapper files, the pipeline parsed 2,793 operation records but only wrote 68 READS/WRITES edges to the graph — a 97% drop.
Root cause (hypothesis)
write_mybatis_links() in writer.py matches by:
MATCH (fn:Function {name: q.method_name, path: q.method_path})But MyBatis mapper XML <select id="findByUserId"> doesn't correspond to actual Java method declarations at a known path. The mapper interface methods are:
- Defined on a Java
interface(e.g.UserMapper.java), not a concrete class - The XML mapper path ≠ the Java interface path
method_pathis set to the XML file path, not the Java interface path
So the MATCH finds no Function nodes and writes 0 edges.
Fix direction
- XML → interface resolution:
mybatis.pyshould find the corresponding Java mapper interface (same base name, e.g.UserMapper.xml→ look forUserMapper.javain the repo) and setmethod_pathto the Java file path - Fallback by class_name + method_name:
write_mybatis_links()should try a looser match:MATCH (fn:Function {name: q.method_name}) WHERE fn.path CONTAINS q.mapper_class— using the mapper class name as a path hint - Interface method nodes: Ensure
interface_declarationmethod nodes are indexed asFunctionnodes (they currently may be skipped)
Validation data
Tested against Codebase B (285K functions):
- 475
*Mapper.xmlfiles found - 2,793 operation records parsed (
<select>,<insert>,<update>,<delete>) - 68 READS/WRITES edges written (all from fallback class_context matching)
- Expected: ~2,000+ edges if Java interface paths are resolved correctly
Related
- Part of Feature: Index external data sources (DBs, BigQuery, Kafka) and link them to code — turn CGC into an architecture graph #843 (datasource architecture graph)
- See
src/codegraphcontext/tools/languages/mybatis.pyandwriter.write_mybatis_links()
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
- Status
Activity
github-actions commentedon May 7, 2026
Hi! 👋 Join our CodeGraphContext Discord channel to collaborate: https://discord.gg/dR4QY32uYQ
fix(java): interface/enum methods get class_context=None; Cassandra @…
fix(java): interface/enum methods get class_context=None; Cassandra @…
bindhurapana-2828 commentedon Jun 8, 2026
Hi
I'd like to work on this issue!
My approach:
mybatis.py: When parsing*Mapper.xml, scan the repo for a matching*Mapper.javainterface file (same base name) and setmethod_pathto the Java file path instead of the XML pathwrite_mybatis_links(): Add a secondary Cypher query usingMATCH (fn:Function {name: q.method_name}) WHERE fn.path CONTAINS q.mapper_classso edges are written even when the exact path resolution missesinterfacenodes are emitted asFunctionnodes during parsing — fixing the root cause ofclass_context=Noneon interface methodsI'll validate against the numbers from the issue (2,793 parsed operations → target ~2,000+ READS/WRITES edges).
Could you please assign this to me? I'm participating in GSSoC '26.
fix(java): interface/enum methods get class_context=None; Cassandra @…
Shashankss1205 commentedon Oct 15, 2026
Maintenance review — 15 October 2026
The key test is XML namespace/method resolution to the Java mapper interface, including overloaded or missing methods. Compare parsed operations with written READS/WRITES edges and expose unmatched counts.
Shashankss1205 commentedon Oct 15, 2026
Continuing the fix with native regressions. Current code matches only class_context, which SCIP functions can lack. Resolution now uses each XML namespace against unique Java declarations already parsed for this repository, then writes by exact source path + method name; duplicate FQNs and unknown sources stay unresolved rather than guessing by basename or leaking into another repository. Native testing additionally exposed DbTable MERGEs keyed by name even though the schema's primary key is fqn; this affects the related ORM mapping/query writers too. Fixing and testing those paths together before publishing.
Shashankss1205 commentedon Oct 15, 2026
Published #1778. Native Kuzu and Ladybug checks now confirm actual READS/WRITES edges, exact Java namespace/path matching, package/repository isolation, MAPS_TO and datasource backfill/preservation. The writer uses the DbTable fqn primary key in all three affected paths. Full local unit suite: 1,698 passed, 8 skipped; targeted writer scope: 63 passed, 1 skipped. CI is running. Existing indexes need a force reindex to recover previously omitted edges; troubleshooting documents this.
Shashankss1205 commentedon Oct 15, 2026
Fixed and merged in #1778 after every current-head CI check passed. Native Kuzu and Ladybug tests confirm real namespace/path-scoped READS/WRITES edges without class_context, no cross-package/repository matches, correct fqn-keyed ORM table writes, MAPS_TO and datasource backfill/preservation. The complete combined fast suite passes 1,828 tests (8 skipped). Re-index affected repositories with cgc index . --force after upgrading to regenerate previously missing links; unresolved/ambiguous namespace warnings explain intentionally skipped records.