Component
Python SDK
Describe the Feature Request
The SDK's query methods can only load related nodes one hop away: prefetch_relationships fetches direct peers, and include accepts only the node's own relationship names. There is no way to ask get()/filters()/all() for a tree of related nodes — e.g. node → relationship → peer's relationship → peer — in a single call.
To read a nested structure today, a consumer must either chain one SDK call per level (N sequential round trips), or drop to execute_graphql() with a hand-written query — which reintroduces exactly what the object layer otherwise avoids: field selections that must be maintained by hand whenever the schema changes.
Describe the Use Case
We build a REST gateway on top of Infrahub that exposes service objects whose natural payload is a nested tree, e.g. a load-balancer service: ServiceVIP → pool → members → member IP addresses (plus the pool's health check). Read endpoints need the whole tree.
With the object layer this is one call per level, and the intermediate levels' code must thread identifiers downward. A partial workaround is filtering on a reverse relationship (client.get("Pool", vip__hostname__value=...) then client.filters("Member", pool__name__value=..., prefetch_relationships=True)), which covers two levels per call — but it requires reverse relationships to be declared in the schema and still costs one round trip per two levels.
The appeal of the object layer for gateway-style integrations is that code stays generic when the schema evolves; retrieving fixed nested shapes is currently the one read pattern where users are pushed back to hand-maintained GraphQL.
Additional Information
generate_query_data() already builds the per-kind selection from the schema at runtime; the limitation is that it has no notion of nesting beyond the first hop.- Verified on SDK 1.22.1 / current Infrahub release.
Component
Python SDK
Describe the Feature Request
The SDK's query methods can only load related nodes one hop away:
prefetch_relationshipsfetches direct peers, andincludeaccepts only the node's own relationship names. There is no way to askget()/filters()/all()for a tree of related nodes — e.g. node → relationship → peer's relationship → peer — in a single call.To read a nested structure today, a consumer must either chain one SDK call per level (N sequential round trips), or drop to
execute_graphql()with a hand-written query — which reintroduces exactly what the object layer otherwise avoids: field selections that must be maintained by hand whenever the schema changes.Describe the Use Case
We build a REST gateway on top of Infrahub that exposes service objects whose natural payload is a nested tree, e.g. a load-balancer service:
ServiceVIP → pool → members → member IP addresses(plus the pool's health check). Read endpoints need the whole tree.With the object layer this is one call per level, and the intermediate levels' code must thread identifiers downward. A partial workaround is filtering on a reverse relationship (
client.get("Pool", vip__hostname__value=...)thenclient.filters("Member", pool__name__value=..., prefetch_relationships=True)), which covers two levels per call — but it requires reverse relationships to be declared in the schema and still costs one round trip per two levels.The appeal of the object layer for gateway-style integrations is that code stays generic when the schema evolves; retrieving fixed nested shapes is currently the one read pattern where users are pushed back to hand-maintained GraphQL.
Additional Information
generate_query_data()already builds the per-kind selection from the schema at runtime; the limitation is that it has no notion of nesting beyond the first hop.