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: createOrder | Contains the top-level mutation input. |
| Level 1: CreateOrderInput | Contains userId and orderItems fields. |
| Level 2: OrderItemInput | Represents each order item, with fields such as productId and quantity, plus a nested shippingAddress. |
| Level 3: ShippingAddressInput | Contains address details like street and city. |
- If ExpandTemporaryTablesDepth is set to 1, the provider creates a child temporary table for orderItems only, without further expanding the shippingAddress field.
- If ExpandTemporaryTablesDepth is set to 2 or higher, the provider 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 provider 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 provider 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.