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.