---
id: add-call-graph-edges-indexes-cascades
name: Add call_graph_edges indexes and cascade documentation
status: completed
depends_on: []
scope: narrow
risk: medium
impact: component
level: implementation
---

## Description

`call_graph_edges` has no indexes and no cascade entries in `table-reference.md`. Both `sourceId` and `targetId` reference `call_graph_nodes.id` with CASCADE (from `call-graph.md`), but this is undocumented in the cross-cutting reference. Without indexes, graph traversal queries (find children, find parents) will require sequential scans.

Additionally, the relationship between `call_graph_nodes.parentRequestId` and `call_graph_edges` is ambiguous: do they store the same parent-child relationship redundantly, or serve different purposes?

## Acceptance Criteria

- [ ] `table-reference.md` index table includes: `idx_call_graph_edges_source_id` on `(sourceId)`, `idx_call_graph_edges_target_id` on `(targetId)`
- [ ] Consider and document whether unique constraint on `(sourceId, targetId, edgeType)` is needed to prevent duplicates
- [ ] `table-reference.md` cascade table includes: `call_graph_edges.sourceId → call_graph_nodes.id` with CASCADE, `call_graph_edges.targetId → call_graph_nodes.id` with CASCADE
- [ ] `call-graph.md` is updated with the index definitions
- [ ] The `parentRequestId` vs `call_graph_edges` relationship is clarified in `call-graph.md`: document whether `parentRequestId` is a convenience shortcut or redundant with edges

## References

- docs/reviews/storage-architecture-review-2026-04-21.md#C10
- docs/architecture/storage/call-graph.md:32-41
- docs/architecture/storage/table-reference.md (missing entries)

## Notes

> To be filled by implementation agent

## Summary

> To be filled on completion