examples · graph · 2 / 7
2. reverse - one-hop inbound adjacency
← Graph exampleswhat this does
Who points at this row? reverse is the mirror of neighbors - same relation, opposite direction. Given the primary key of a target row, returns the array of primary keys that have an edge pointing to it.
when to use it
- "Which orders bought this product?" - the inverse of the forward query.
- Anywhere you would scan a table to find rows whose foreign key matches a value.
- Building inbound feeds, audit trails, "referenced by" panels.
schema requirement
The relation must be declared with bidirectional = true - which is the default. If a relation is one-way only, reverse on it returns 400. See schemas/reference#relations.
the request
GET /v1/tenants/:t/graph/:schema/reverse?rel=...&pk=...
curl "https://$OC_HOST/v1/tenants/$OC_TENANT/graph/shop.orders/reverse?rel=bought_product&pk=p001" \
-H "Authorization: Bearer $OC_TOKEN"result = db.graph.reverse(
"shop.orders",
rel="bought_product",
pk="p001",
)const result = await db.graph.reverse("shop.orders", {
rel: "bought_product",
pk: "p001",
});result, _ := db.Graph().Reverse(ctx, "shop.orders", originchain.ReverseRequest{
Rel: "bought_product",
PK: "p001",
}) what you get back
[
"o001",
"o042",
"o118"
] A flat array of source primary keys. Same shape as neighbors, just walking the other direction.
how it works
- When the relation is bidirectional, the write path lays down a second adjacency entry keyed by the target.
- reverse is then a point lookup against that inbound entry - identical cost profile to neighbors.
- The cost is the price of bidirectionality: storage roughly doubles for the edge, but reads stay O(fan-in).
common mistakes
- Relation set to
bidirectional = false. reverse refuses to run. Re-declare the relation or use forward traversal from the other side. - High fan-in nodes. A "popular" product can have hundreds of thousands of inbound edges. Paginate at the call site or use pagerank when you want ranked influence rather than the raw list.