ExpandArgumentsDepth
Specifies the depth the provider searches for columns within nested GraphQL arguments of type INPUT_OBJECT. Higher values expand deeper levels of nested fields, while lower values limit the expansion.
Data Type
int
Default Value
2
Remarks
The ExpandArgumentsDepth property determines how many levels of nested input objects are traversed and expanded into separate SQL columns by the connector. This property directly impacts which fields from your GraphQL input are accessible in SQL queries and can affect both query complexity and performance.
Example Schema
For example, consider the following GraphQL schema:
type Query {
filteredCompanies(input: FilteredCompaniesInput!): [Company]
}
input FilteredCompaniesInput {
filters: FiltersInput
}
input FiltersInput {
type: String
details: DetailsInput
}
input DetailsInput {
region: String
category: String
}
Nesting Levels
In this schema, the nesting levels are as follows:
| Level 0: FilteredCompaniesInput | Contains only the nested filters field. No primitive fields exist at this level to flatten. |
| Level 1: FiltersInput | Exposes the type field. |
| Level 2: DetailsInput | Exposes the region and category fields. |
- If ExpandArgumentsDepth is set to 1, then only the type field from FiltersInput is exposed as a column.
- If ExpandArgumentsDepth is set to 2, the connector also exposes fields from DetailsInput. In this case, region and category.
Example Query
In the following GraphQL operation, the filters argument is an INPUT_OBJECT:
{
"variables": {
"input": {
"filters": {
"details": {
"category": "RETAILER"
},
"type": "SUPPLIER"
}
}
},
"query": "query($input:FilteredCompaniesInput!) {\r\nfilteredCompanies(input:$input) {\r\nid:id\r\nvalue:value\r\n}\r\n}\r\n"
}
With ExpandArgumentsDepth=2, you can run a SQL query that leverages those expanded fields. For example:
SELECT id, value FROM filteredCompanies WHERE input_filters_type='SUPPLIER' AND input_filters_details_category='RETAILER'
Performance Considerations
Increasing the depth exposes more nested fields but may increase the complexity and processing time for queries against complex schemas. Reducing the depth may improve performance but can limit access to deeply nested fields. Set this property based on your application’s requirements to balance data accessibility and performance.