# ADR — Use SPARQL DELETE (not ORM `ngSet.delete()`) to remove objects

**Date:** 2026-03-17 · **Status:** Accepted → Superseded (2026-06-15). Historical
decision, ported for the current-SDK behaviour it records. Original context: the
consuming app.

> **Superseded (2026-06-15).** The `ngSet.delete()` non-persistence bug that
> motivated this decision was largely fixed upstream in `@ng-org/orm`; deletion
> code went back to `ngSet.delete()`. Kept as arbitration memory — the CRDT
> conflict rule ("don't combine the two") **still holds**.

## Context

Removing an object from the NextGraph store: `DeepSignalSet.delete()` updates the
local reactive state (immediate UI) but **does not persist** to the broker — after
refresh the object reappears.

## Options considered

### A — ORM `ngSet.delete(item)`
Official API, instant local reactive update. **Against:** did not persist in
practice (`delete()` returned `true`, local set updated, object back after
refresh); `graph_orm_update` seemed to mishandle "remove" patches for top-level
set objects (likely engine bug); failed silently.

### B — `ng.sparql_update()` with SPARQL DELETE
`DELETE WHERE { GRAPH <graph> { <subject> ?p ?o } }` removes all the RDF triples.
**For:** persists (survives refresh); the broker confirms via a `GraphOrmUpdate`
`op: "remove"` that reactively removes the item from the ORM set; direct control.
**Against:** not instant (~50ms SPARQL round-trip + broker callback); must NOT be
combined with `ngSet.delete()`.

### C — both together
**Does not work:** the ORM `.delete()` patch and the SPARQL DELETE conflict at the
CRDT level → neither UI nor persistence.

## Decision

**Option B — SPARQL DELETE alone.** The broker returns a `GraphOrmUpdate`
`op: "remove"` that reactively removes the item from the ORM set (UI updates, just
not synchronously). **Do NOT** call `ngSet.delete()` alongside.

```ts
await ng.sparql_update(
  session_id,
  `DELETE WHERE { GRAPH <${partGraph}> { <${partId}> ?p ?o } }`,
  partGraph,
);
```

This is the authoritative-delete pattern this lib's emulation relies on for inbox
deposits and shim graphs (an interpolated NURI/subject must pass through
`assertNuri`/`escapeLiteral` first — see SPARQL hardening in
[`../simulation.md`](../simulation.md)).

## Consequences

- **Positive:** deletion persists; single source of truth (broker → ORM → UI).
- **Negative:** slight UI delay (~50ms); diverges from the ORM README examples.
- **Risk:** if `ng.sparql_update` changes, this breaks; revisit as `ngSet.delete()`
  matures upstream.