Power BI Connector for GraphQL

Build 25.0.9454

ExpandTemporaryTablesDepth

Specifies the depth at which the provider includes nested child temporary tables in the schema. This property only takes effect when the ExposeDynamicProcedures property is set to true.

Data Type

int

Default Value

5

Remarks

The ExpandTemporaryTablesDepth property controls how many levels of nested input objects in GraphQL mutations are converted into separate temporary tables in the relational model. This ensures that the hierarchical structure of your mutation input is preserved when dynamic procedures are exposed.

Example Schema

For example, consider the following GraphQL schema:

type Mutation {
  createOrder(input: CreateOrderInput!): CreateOrderPayload
}

input CreateOrderInput {
  userId: ID!
  orderItems: [OrderItemInput!]!
}

input OrderItemInput {
  productId: ID!
  quantity: Int!
  shippingAddress: [ShippingAddressInput!]
}

input ShippingAddressInput {
  street: String!
  city: String!
}

type CreateOrderPayload {
  order: Order
}

type Order {
  id: ID!
  orderItems: [OrderItem!]!
}

type OrderItem {
  id: ID!
  shippingAddress: ShippingAddress
}

type ShippingAddress {
  street: String!
  city: String!
}

Nesting Levels

In this schema, the nesting levels are as follows:

Level 0: createOrderContains the top-level mutation input.
Level 1: CreateOrderInputContains userId and orderItems fields.
Level 2: OrderItemInputRepresents each order item, with fields such as productId and quantity, plus a nested shippingAddress.
Level 3: ShippingAddressInputContains address details like street and city.

  • If ExpandTemporaryTablesDepth is set to 1, the connector creates a child temporary table for orderItems only, without further expanding the shippingAddress field.
  • If ExpandTemporaryTablesDepth is set to 2 or higher, the connector also creates a separate child temporary table for shippingAddress, mapping its nested fields such as street and city to individual columns.

This property controls how many levels of nested child temporary tables the connector includes in the relational schema when dynamic procedures are exposed. It is most relevant to GraphQL mutations that include nested input objects.

Example Mutation

Consider the following GraphQL mutation:

mutation {
  createOrder(input: {
    userId: 123,
    orderItems: [
      {
        productId: 456,
        quantity: 2,
        shippingAddress: {
          street: "123 Main St",
          city: "Seattle"
        }
      }
    ]
  }) {
    order {
      id,
      orderItems {
        id,
        shippingAddress {
          street,
          city
        }
      }
    }
  }
}

With ExpandTemporaryTablesDepth set appropriately, the connector examines each level of nested input objects in your mutation and creates a temporary table for any field that returns a list at that level. This means that the hierarchical structure of your mutation input is preserved in the relational model and each nested object up to the specified depth is mapped to its own table. For instance, if your mutation input includes a top-level object with a nested array of order items and each order item contains a nested shipping address, setting the property to 2 ensures that there is a temporary table for the order items as well as for the shipping addresses.

Performance Considerations

Increasing the depth enables access to more deeply nested mutation inputs but can result in a more complex schema and higher processing overhead. A lower depth simplifies the schema and improves performance but may limit access to deeply nested data. Adjust this property based on your application's requirements.

Copyright (c) 2025 CData Software, Inc. - All rights reserved.
Build 25.0.9454