This article covers field support for filtering and sorting in Query Service Options And Variants (SDK | REST).
The following table shows field support for filters for the
serviceOptionsAndVariants object:
| Field | Supported Filters | Sortable |
|---|---|---|
id | $eq, $ne, $in | Sortable |
serviceId | $eq, $ne, $in | Sortable |
options.values | $exists | |
options.values.id | $hasSome, $hasAll | |
options.values.type | $hasSome, $hasAll | |
options.values.optionSpecificData.customData.name | $hasSome, $hasAll | |
variants.values | $exists | |
variants.values.choices.choice.custom.value | $hasSome, $hasAll | |
variants.values.price | $hasSome, $hasAll | |
variants.values.choices.optionId | $hasSome, $hasAll |
Query Service Options And Variants (SDK | REST) runs with this default:
id in ASC order.cursorPaging.limit set to 100.Specify the sort object in the following format:
"sort" : [
{
"fieldName":"sortField1",
"order":"ASC"
},
{
"fieldName":"sortField2",
"order":"ASC"
},
]By default pagingMetadata.cursors are returned, unless you specifically pass
query.paging.
The maximum for cursorPaging.limit is 100.
If you pass a cursor token that you've received in a previous query response, passing additional sort or filter information results in an invalid cursor error. This is because the received cursor token already holds all the needed information for sort and filter. Changing the sort and filter properties during the span of a cursor query isn't supported. You may provide a different limit though.