view release on metacpan or  search on metacpan

docs/adr/0001-resolvers-pass-column-hashrefs-as-nodes.md  view on Meta::CPAN

## Decision

The GraphQL node is a **detached column hashref**, never a live DBIO row.
Every resolver materialises its return value with `{ $row->get_columns }`
(or a list of them) at the boundary, and downstream resolvers operate on
that hashref.

Where a child resolver genuinely needs the row back — relationship
traversal — it **re-finds the row by primary key** rather than keeping a row
reference alive. `DBIO::GraphQL::Relationship::build_field`'s resolver
detects a hashref parent (`if (ref($row) eq 'HASH')`) and calls
`_pk_find($ctx, $moniker, $row)` (`Relationship.pm`, the `_pk_find` helper),
which reads the source's `primary_columns`, pulls the PK values out of the
hashref, and issues a fresh `$ctx->resultset($moniker)->find(...)`. Only then
does it traverse `$row->$rel_name`.

## Rationale

A live-row node couples the GraphQL object graph to ORM row lifetime,
identity, and the surrounding transaction/connection. A detached hashref is