# Filters
Hormo Studio supports a specific filter syntax: it’s a lot like SQL, but designed specifically to serialize safely without injection and to be native to JavaScript. The following table describes Hormo Stuiod's filter types:
| Filter type | Type | Description |
| ------------- | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| fields | Object, Array, or String | Specify fields to include in or exclude from the response. See [Fields filter](https://loopback.io/doc/en/lb2/Fields-filter.html). |
| include | String, Object, or Array | Include results from related models, for relations such as belongsTo and hasMany.
See Include filter.
|
| limit | Number | Limit the number of instances to return.
See Limit filter.
|
| order | String | Specify sort order: ascending or descending. See [Order filter](https://loopback.io/doc/en/lb2/Order-filter.html). |
| skip (offset) | Number | Skip the specified number of instances.See [Skip filter](https://loopback.io/doc/en/lb2/Skip-filter.html). |
| where | Object | Specify search criteria; similar to a WHERE clause in SQL. See [Where filter](https://loopback.io/doc/en/lb2/Where-filter.html). |
**Fields filter**
A *fields* filter specifies properties (fields) to include or exclude from the results.
```
filter[fields][_propertyName_]=&filter[fields][propertyName]=...
```
You can also use stringified JSON format in a REST query
## Include filter
An *include* filter enables you to include results from related models in a query, for example models that have belongsTo or hasMany relations, to optimize the number of requests. See [Creating model relations](https://docs.hormo.studio/models/relations) for more information. The value of the include filter can be a string, an array, or an object.
`filter[include][`*`relatedModel`*`]=`*`propertyName`*
These examples assume a customer model with a hasMany relationship to a reviews model. Return all customers including their reviews:
```
/customers?filter[include]=reviews
```
Return all customers including their reviews which also includes the author:
```
/customers?filter[include][reviews]=author
```
Return all customers whose age is 21, including their reviews which also includes the author:
```
/customers?filter[include][reviews]=author&filter[where][age]=21
```
Return first two customers including their reviews which also includes the author
```
/customers?filter[include][reviews]=author&filter[limit]=2
```
Return all customers including their reviews and orders
```
/customers?filter[include]=reviews&filter[include]=orders
```
## Limit filter
A *limit* filter limits the number of records returned to the specified number (or less).
Return only the first five query results:
## Order filter
An *order* filter specifies how to sort the results: ascending (ASC) or descending (DESC) based on the specified property. Order by one property:
```
filter[order]=propertyName
```
Order by two or more properties:
```
filter[order][0]=propertyName &filter[order][1][propertyName]=...
```
Return the three loudest three weapons, sorted by the `audibleRange` property:
```
/weapons?filter[order]=audibleRange%20DESC&filter[limit]=3
```
## Skip filter
A skip filter omits the specified number of returned records. This is useful, for example, to paginate responses. Use `offset` as an alias for `skip`.
This REST request skips the first 50 records returned:
**Pagination Example** The following REST requests illustrate how to paginate a query result. Each request request returns ten records: the first returns the first ten, the second returns the 11th through the 20th, and so on…
```
/cars?filter[limit]=10&filter[skip]=0 /cars?filter[limit]=10&filter[skip]=10 /cars?filter[limit]=10&filter[skip]=20 ...
```
## Where filter
A *where* filter specifies a set of logical conditions to match, similar to a WHERE clause in a SQL query.
In the first form below, the condition is equivalence, that is, it tests whether *property* equals *value*. The second form below is for all other conditions.
```
filter[where][property]=value filter[where][property][op]=value
```
For example, if there is a cars model with an `odo` property, the following query finds instances where the `odo` is greater than 5000:
```
/cars?filter[where][odo][gt]=5000
```
For example, here is a query to find cars with `odo` is less than 30,000:
```
/cars?filter[where][odo][lt]=30000
```
Encode the large filter object as “stringified JSON.”
**Encode filter object as JSON**
```
http://localhost:3000/api/Books?filter={"where":{"or":[{"id":1},{"id":2},...,{"id":20"},{"id":21}]}}
```
## Operators
This table describes the operators available in “where” filters. See Examples below.
| Operator | Description |
| ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| = | Equivalence |
| and | Logical AND operator |
| or | Logical OR operator |
| gt, gte | Numerical greater than (>); greater than or equal (>=). Valid only for numerical and date values. |
| lt, lte | Numerical less than (<); less than or equal (<=). Valid only for numerical and date values.For geolocation values, the units are in miles by default. |
| between | True if the value is between the two specified values: greater than or equal to first value and less than or equal to second value. |
| inq, nin | In / not in an array of values. |
| near | For geolocations, return the closest points, sorted in order of distance. Use with `limit` to return the *n* closest points. |
| neq | Not equal (!=) |
| like, nlike | LIKE / NOT LIKE operators for use with regular expressions. The regular expression format depends on the backend data source. |
| ilike, nilike | ILIKE / NOT ILIKE operators for use with regular expressions. The regular expression format depends on the backend data source. |
| regexp | Regular expression. |
**AND and OR operators** \
Use the AND and OR operators to create compound logical filters based on simple where filter conditions, using the following syntax.
```
[where][][0]condition1&[where][]condition2...
```
Where *condition1* and *condition2* are a filter conditions.
**Regular expressions** \
You can use regular expressions in a where filter, with the following syntax. You can use a regular expression in a where clause for updates and deletes, as well as queries. Essentially, `regexp` is just like an operator in which you provide a regular expression value as the comparison value.
**Tip:** A regular expression value can also include one or more [flags](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions#Advanced_searching_with_flags). For example, append `/i` to the regular expression to perform a case-insensitive match.
Where `` can be a:
* String defining a regular expression (for example, `'^foo'` ).
* Regular expression literal (for example, `/^foo/` ).
* Regular expression object (for example, `new RegExp(/John/)`).
Or, in a simpler format:
```
{where: {property: }}}
```
Where `` can be a:
* Regular expression literal (for example, `/^foo/` ).
* Regular expression object (for example, `new RegExp(/John/)`).
For more information on JavaScript regular expressions, see [Regular Expressions (Mozilla Developer Network)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions).
```
filter[where][property][regexp]=expression
```
Where:
* *property* is the name of a property (field) in the model being queried.
* *expression* is the JavaScript regular expression string. See [Regular Expressions (Mozilla Developer Network)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions).
The following REST query returns all cars for which the model starts with a capital “T”::
```
/api/cars?filter[where][model][regexp]=^T
```
The following REST query returns all models that start with either an uppercase “T” or lowercase “t”:
```
/api/cars?filter[where][model][regexp]=/^t/i
```
Note that since the regular expression includes a flag, it is preceded by a slash (`/`).
## Examples
**Equivalence** Weapons with name M1911:
```
/weapons?filter[where][name]=M1911
```
Cars where carClass is “fullsize”:
```
/api/cars?filter[where][carClass]=fullsize
```
**gt and lt**
For example, the following query returns all instances of the employee model using a *where* filter that specifies a date property after (greater than) the specified date:
```
/employees?filter[where][date][gt]=2014-04-01T18:30:00.000Z
```
The top three weapons with a range over 900 meters:
```
/weapons?filter[where][effectiveRange][gt]=900&filter[limit]=3
```
Weapons with audibleRange less than 10:
```
/weapons?filter[where][audibleRange][lt]=10
```
**and / or** The following code is an example of using the “and” operator to find posts where the title is “My Post” and content is “Hello”.
```
?filter[where][and][0][title]=My%20Post&filter[where][and][1][content]=Hello
```
**between** Example of between operator:
```
filter[where][price][between][0]=0&filter[where][price][between][1]=7
```
**near** The `where..near` filter is different from other where filters: most where filters **limit** the number of records returned, whereas `near` **orders** them, making it more like a SQL `order by`clause. By combining it with `[limit](https://loopback.io/doc/en/lb2/Limit-filter.html)`, you can create a query to get, for example, the **three records nearest to a given location**. For example:
```
/locations?filter[where][geo][near]=153.536,-28.1&filter[limit]=3
```
**Inq** The inq operator checks whether the value of the specified property matches any of the values provided in an array. The general syntax is:
```
{where: { property: { inq: [val1, val2, ...]}}}
```
Where:
* *property* is the name of a property (field) in the model being queried.
* *val1, val2*, and so on, are literal values in an array.
Example of inq operator:
```
/medias?filter[where][keywords][inq]=foo&filter[where][keywords][inq]=bar
```
Or
```
?filter={"where": {"keywords": {"inq": ["foo", "bar"]}}}
```
{% content-ref url="access-token" %}
[access-token](https://docs.hormo.studio/restful-api/access-token)
{% endcontent-ref %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.hormo.studio/restful-api/filters.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.