RQL in Five Minutes

The pipeline

from names the source. filter keeps matching rows. map picks the shape of the output. sort orders it. Each step consumes the previous step's rows, so you read a query the same way it executes:

There is no SELECT in RQL, and no inside-out reading order.

Start from any data

A pipeline usually starts from a table or view, but it can start from inline records too. Handy for prototyping an expression before you have a schema:

Shape rows with map

map selects columns and computes new ones. take caps the result. Combined with sort, that is SQL's SELECT ... ORDER BY ... LIMIT in three readable lines:

Aggregate by group

aggregate ... by groups rows and reduces each group. Aggregation functions are namespaced, like everything callable in RQL: math::sum, math::avg, math::count:

An empty by {} aggregates the whole input into a single row.

Missing values are none

RQL has no null. A missing value is written none, and it is typed: a missing int4 is still an int4. Arithmetic propagates it instead of failing:

Test for it explicitly with is::some and is::none:

Variables

let binds a value you can reuse anywhere in the statement. RQL also has control flow (if, loop, match) for scripting beyond single queries:

Where RQL goes further

The same pipeline syntax defines derived state that ReifyDB maintains for you: transactional and deferred views, windowed aggregation over live data, and rows that expire via TTL. That is the point of an application state database: queries you would otherwise re-run become state the database keeps current.

• --Quickstart - build a live view and watch it maintain itself
• --RQL for SQL users - a direct translation table from SQL
• --Pipeline operators - the full operator reference