Send Docs Feedback

Note: Most user interface tasks can be performed in Edge Classic or the New Edge experience. For an overview, getting started topics, and release notes specific to the New Edge experience, see the docs.

Supported query operators & data types

The following operators and data types are supported by the SQL-like query language in API BaaS.

Operators

Operator Purpose Example
'<' or 'lt' Less than select * where quantity > 1000
'<=' or 'lte' Less than or equal to select * where quantity <= 1000
'=' or 'eq' Equal select * where price = 20.00
'>=' or 'gte' Greater than or equal to select * where quantity >= 1000
'>' or 'gt' Greater than select * where quantity > 1000
not <some_expression> Subtraction of results, not equal select * where quantity < 4000 and not quantity = 2000
select * where not quantity = 1000
contains Narrow by contained text. Finds whole words in a string only. select * where title contains 'tale'
and Intersection of results select * where quantity > 1000 and quantity < 4000
or Union of results select * where quantity = 1000 or quantity = 4000

Precedence

In the table above, the operators listed towards the bottom have lower precedence than the operators listed at the top. When a query is evaluated the comparison operators (=, >, <, <= and >=) will be evaluated first, in the order that they appear in the query. Next, the not, contains, and, and or operators will be evaluated, in that order.

Though not shown above, parentheses may be used to group query expressions and further control the order of precedence. For example, given the rules of precedence, the following two queries are equivalent:

select * where age > 6 or size = 'large' and color = 'tabby'
select * where age > 6 or (size = 'large' and color = 'tabby')

Data types

As you develop queries, remember that entity properties each conform to a particular data type. For example, in the default entity User, the name property is stored as a string, the created date as a long, and metadata is stored as a JSON object. Your queries must be data type-aware to ensure that query results are as you expect them to be.

Note that using a floating point values to represent currency can yield unexpected results when filtering on those values in a query. For this reason, to represent currency, use the best practice of representing the value as a corresponding non-decimal alternative. For example, in American currency, for a value of 10.22 (10 dollars and 22 cents), store the value instead as 1022 (1 thousand 22 cents). You'd then query for the value as price=1022.

For a list of property data types for each default entities, see Default Data Entity Types.

Data Type Examples
string 'value', unicode '\uFFFF', octal '\0707'
long
1357412326021

Timestamps are typically stored as long values.

float
10.1, -10.1, 10e10, 10e-10, 10E10, 10E-10

Your query must be specific about the value you're looking for, down to the value (if any) after the decimal point.

boolean
true | false
UUID
ee912c4b-5769-11e2-924d-02e81ac5a17b
Array
["boat", "car", "bike"]
object

For a JSON object like this one:

{
 "items": [
  {
   "name": "rocks"
  },
  {
   "name": "boats"
  }
 ]
}

you can use dot notation to reach property values in the object:

/mycollection/thing?ql="select * where items.name = 'rocks'"

Objects are often used to contain entity metadata, such as the activities associated with a user, the users associated with a role, and so on.

Please note that object properties are not indexed. This means queries using dot-notation will be much slower than queries on indexed entity properties.

 

Help or comments?