Find records that link to a target
The language tabs use earlier client interfaces. Check SDK versions and connection setup before running them.
Follow a relationship backwards to find rows that point to a selected record.
Before you run it: Bidirectional lookup is required. A target with many incoming links can produce a large response.
First load the order-to-product sample dataset. It creates shop.orders.bought_product with the exact IDs used below.
With that sample dataset, pass product key p001 and expect order key o001. This request reverses the declared relation; it does not reverse the spelling of the table names.
- Start at product p001Use the target record's primary key.
- Follow incoming linksRead the reverse side of bought_product.
- Receive order o001Inspect the source IDs that reference this product.
Follow the example
- Enable reverse traversal in the relationship.
- Write the linked rows.
- Pass the target primary key.
- Read the returned source keys.
Set up the relationship
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.
Run the request
curl "https://$OC_HOST/v1/tenants/$OC_TENANT/graph/shop.orders/reverse?rel=bought_product&pk=p001" \
-H "Authorization: Bearer $OC_TOKEN"Check the result
The result lists incoming rather than outgoing neighbors.
[
"o001",
"o042",
"o118"
]A flat array of source primary keys. Same shape as neighbors, just walking the other direction.
Understand the behavior
- 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).
Important limits and checks
- 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. Check the response-size limit before fetching the list. Splitting it for display in your application does not reduce the database response size. PageRank answers a different question about influence.