The query language described in this article is implemented partially or in full by Wix SDK APIs that support querying capabilities.
There are 2 types of querying techniques used in the SDK. Check the SDK Reference to see which technique a specific query function supports.
With query builders: You call query functions that build a query to retrieve a list of items. You can recognize these query functions because they have associated <item>QueryBuilder
and <item>QueryResult
class objects. This is the standard SDK querying technique.
These query functions do not use the API query language syntax described here.
Without query builders: Some query functions retrieve a list of items using the API Query Language described in this article. For these queries, pass an object defining the query to the query function.
You can pass some or all of the following properties to the query function to define the query:
filter
:
Which results to return.sort
:
In what order.paging
:
Return only some of the matched entities.fields
:
Field projection. Returns only part of each entity.fieldsets
:
Predefined, named sets of fields for common use cases.
This is a shorthand provided by individual APIs.Usually these query properties are contained in a query
object.
query
object might be wrapped inside an options
object.options
object (without being wrapped in a query
object).Check the SDK Reference to see how to define the object you need to pass to a specific query function.
Specifying an empty object as a parameter to a query function returns all items according to the API's default paging and sort order.
The filter
is a single object { }
with the following syntax for specifying operators:
The format { "<field>": <value> }
specifies an equality condition.
For example, { "status": "DONE" }
matches all entities where status
is "DONE"
.
Operators use the format { "<field>": { "$<operator>": <value> } }
.
For example, { "status": { "$in": ["PENDING", "DONE"] } }
matches all entities where status is "PENDING"
or "DONE"
.
The operators specified below are supported. See the specific API for information on supported filter options for the query function you are using.
$eq
: Matches values that are equal to a specified value.$ne
: Matches all values that are not equal to a specified value.$gt
: Matches values that are greater than a specified value.$gte
: Matches values that are greater than or equal to a specified value.$lt
: Matches values that are less than a specified value.$lte
: Matches values that are less than or equal to a specified value.$in
: Matches any of the values specified in an array.$nin
: Matches none of the values specified in an array.$startsWith
: Matches strings that start with a specified value. Not case-sensitive.$isEmpty
: Matches strings or arrays that are empty or not empty,
depending on whether the specified operand is true
or false
.$and
: Joins query clauses with a logical AND
and returns all items that match the conditions of both clauses.$or
: Joins query clauses with a logical OR
and returns all items that match the conditions of either clause.$not
: Inverts the effect of a query expression
and returns items that don't match the query expression.$exists
: Matches items where the specified field exists and has a non-null value.$hasAll
: Matches arrays that contain all elements specified in the query.$hasSome
: Matches arrays that contain at least one element specified in the query.In the following example, the compound query returns all entities where the status equals "A"
and either qty
is less than 30
or item
starts with the character p
:
1
The following example queries entities where the field tags
value is an array with exactly two elements, "red"
and "blank"
, in the specified order:
1
The following example queries for all entities where tags
is an array that contains the string "red"
as one of its elements, or that tags
is the string "red"
:
1
The following query matches entities that do not contain the item
field, or where the item
field has no value:
1
sort
is an array of field names and sort order.
If order
is not specified for a field, the field is sorted in ascending order.
Sorting is applied to the first sort
item, then the second, and so on:
1
The paging
object describes the size of the data set to return per response and how many records to skip. Each API can support offset paging, cursor paging, or both.
Check the SDK Reference to see the supported paging options for a specific query function.
With offset paging, you provide a limit
and offset
with each request.
To retrieve additional pages, submit subsequent requests with an increased offset
equal to the previous page's limit
plus offset
.
For example, this offset request returns records 41 through 60:
1
With cursor paging, each request returns a cursors
object that contains cursor strings that point to the next page, previous page, or both. To retrieve either page, use the returned next
or prev
cursor in the next request's cursor
parameter.
For example, consider this object:
1
You can use the returned next
cursor to retrieve the next page of results by forming a request like this:
1
fields
is an array of field paths to return.
If a field path points to an object, the entire sub-object is returned.
Subsets of sub-objects can be returned by using dot notation.
In this example, the returned entities contain firstName
from the name
sub-object and the entire address
object:
1
If both fields
and fieldsets
exist, the union of both is returned.
An API may provide named projections to save clients from specifying individual fields in common cases.
For example, the Contacts API implements a fieldset named BASIC
that contains only id
, revision
, info.name.first
, info.name.last
, primaryInfo.email
, and primaryInfo.phone
.
To use a fieldset, specify its name in the fieldsets
array.
For example:
1
If both fieldsets
and fields
exist, the union of both is returned.