fix(query): route named-graph SPARQL DELETE/INSERT WHERE to the target graph (and make MODIFY durable)

[teipsum]

Fixes #367.

What was wrong

Named-graph SPARQL Update worked for the concrete-term forms (INSERT DATA,
DELETE DATA) and DROP GRAPH, but the pattern / MODIFY path ignored the
target graph entirely. The result was a set of silent failures (no error, no
warning):

• a GRAPH-wrapped INSERT ... WHERE mis-wrote into the default graph
  (data corruption);
• a GRAPH-wrapped DELETE WHERE was a silent no-op;
• a WITH <g> MODIFY with an unqualified WHERE bound zero rows and no-oped;
• a DELETE/INSERT ... WHERE MODIFY emitted no WAL record, so it was lost
  on wal-directory replay (even on the default graph).

See the linked issue for runnable repros.

Root cause (paths/lines at main, 4ebae02)

The concrete-term operators already resolve the per-graph sub-store via the
existing RdfStore::graph / graph_or_create API; the pattern/MODIFY family
did not. Specifically:

• Translator dropped the GRAPH block.
  SparqlTranslator::extract_triples_from_pattern
  (crates/grafeo-engine/src/query/translators/sparql.rs:487) matched only
  Basic / Group and returned Vec::new() for NamedGraph, so a
  GRAPH-wrapped DELETE WHERE produced an empty template; DeleteTripleOp.graph
  was hard-coded None (sparql.rs:469).
• Pattern executors used the bare default store.
  RdfInsertPatternOperator (rdf/mod.rs:1850) and RdfDeletePatternOperator
  (rdf/mod.rs:2134) called store.insert / store.remove on the default
  store and logged graph: None to WAL/CDC
  (rdf/mod.rs:1861/1873, 2145/2157).
• MODIFY executor ignored template.graph.
  RdfModifyOperator::next (rdf/mod.rs:2688) deleted via store.remove
  (:2720) and inserted via store.insert (:2793) on the default store, and
  the struct had no WAL field at all.
• Read side never redirected for WITH.
  SparqlTranslator::translate_modify (sparql.rs:498) built the WHERE plan
  with self.dataset = None, so an unqualified WHERE under WITH <g> scanned
  the default graph (contrast translate_select, which sets self.dataset).
• USING was dropped at dispatch (sparql.rs:334, using_clauses: _).

The fix

Two logical commits in one PR.

Commit 1 — routing correctness

• extract_triples_from_pattern descends into GRAPH blocks and tags each
  extracted triple with its enclosing graph; translate_delete_where sets
  DeleteTripleOp.graph accordingly.
• RdfInsertPatternOperator, RdfDeletePatternOperator and RdfModifyOperator
  resolve the per-template named sub-store and insert/remove there, with the
  resolved graph carried into the CDC events (and the pattern operators' WAL
  records). The delete path uses the non-creating graph lookup so a
  zero-match named delete never materialises an empty sub-store.
• translate_modify redirects the WHERE clause's default graph to the WITH
  graph before planning it, mirroring translate_select, so an unqualified
  WITH-scoped WHERE binds in the named graph. A GRAPH-wrapped WHERE still binds
  through the existing graph-context stack and is unaffected.
• Fail closed on variants that cannot be routed: USING / USING NAMED and a
  variable graph target (GRAPH ?g) now return an explicit error instead of
  silently dropping the clause or mis-targeting.
• Documents the transaction-handle atomicity contract on
  Session::execute_sparql.

Commit 2 — MODIFY durability

RdfModifyOperator now emits InsertRdfTriple / DeleteRdfTriple WAL records
for the triples it inserts and removes, carrying the resolved per-template
graph. WAL replay already routes by the record's graph field, so this is a
writer-side-only change. The operator receives the session WAL handle through
plan_modify, the same way the pattern operators already do.

Tests

• tests/spec/rdf/sparql/update_advanced.gtest: named-graph MODIFY oracles —
  the mis-write (named gets the triple, default stays empty), the fingerprint
  trio (named DELETE WHERE deletes, default still works, DROP GRAPH still
  works), the GRAPH-wrapped MODIFY rename, and the WITH read-side binding.
• crates/grafeo-engine/tests/named_graph_modify.rs: the store-level
  mis-write check, the non-creating-on-zero-match-delete invariant, and the
  fail-closed USING / variable-graph guards (including the zero-binding case).
• crates/grafeo-engine/tests/named_graph_modify_durability.rs: close/reopen
  WAL-replay durability for a named-graph and a default-graph MODIFY.

All four touched crates pass (grafeo-engine, grafeo-core,
grafeo-adapters, grafeo-spec-tests); cargo fmt and
cargo clippy --all-targets --all-features -- -D warnings are clean.

Notes / scope

• No store-API change: the per-graph sub-store API already exists; this reuses
  it on the pattern/MODIFY path.
• LPG/Cypher/Gremlin mutation is a separate store and is untouched.
• The pattern/MODIFY operators remain non-transactional (unchanged,
  pre-existing). Honest caveat: happy to split this into more commits/PRs if
  preferred.

---

Summary by cubic

Routes named-graph SPARQL DELETE/INSERT WHERE (MODIFY) to the correct graph and makes MODIFY durable via WAL. Fixes silent no-ops, wrong-graph writes, and data loss on WAL replay.

• Bug Fixes

  • GRAPH-wrapped deletes/inserts now target the named graph; the default graph is untouched.
  • WITH now scopes the WHERE plan to that graph; unqualified patterns bind in .
  • Pattern and MODIFY executors resolve the per-template graph; deletes use non-creating lookup; CDC/WAL include the graph.
  • Unsupported variants fail closed with clear errors: USING/USING NAMED and GRAPH ?g.
  • MODIFY emits WAL records for inserts/deletes (with graph), so changes persist across close/reopen.

• Migration

  • Replace USING/USING NAMED in MODIFY with WITH <g> or explicit GRAPH <g>.
  • Avoid GRAPH ?g in DELETE/INSERT templates; use a concrete graph IRI.

^{Written for commit 417d629. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 6 files

_{Re-trigger cubic}

[codecov]

Codecov Report

❌ Patch coverage is 99.27536% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...ates/grafeo-engine/src/query/translators/sparql.rs	97.61%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[codspeed-hq]

Merging this PR will not alter performance

✅ 70 untouched benchmarks

---

_{Comparing teipsum:fix-named-graph-modify (417d629) with main (4ebae02)}