...
Query api provides a pipeline based data query approach. Contrary to SQL which provides a declarative language that describe the data query in a single (but sometime complex) statement, pipeline based data queries gives the user the ability describe his query as a sequence of data transformation stages.
Stages can be seen as a data transformation node that takes a table as input and provides a table as output.
...
As we can see each stage can only refer to
its input table columns (which is the previous stage output). For instance, the InnerJoin stage is referring to Products table sku via
input.sku
and if it is present, columns from a concrete source table. For instance,
Products
for the Source stage andCosts
for the InnerJoin stage.
The above example is implemented with QueryApi as follows:
...
of a concrete table when it is belonging to its arguments. This is the case
of the source stage which uses p to refer to the concrete product table columns
source(p, [p.sku(), p.label()])
the join stage which uses c to refer to the concrete costs table columns
innerJoin(c, { input -> [c.Cost] }, { input -> input.sku.equal(c.sku()) })
of the table view it gets as input. To refer to these columns the client code should provide a function getting a
Tables.Columns
object which give access to this input columns. In the above example this is the case for the last three stages of the query pipeline.
Tables.Columns
objects are object is an immutable map associating columns names to their reference. As groovy supports the .
operator to access the entry of a map, columns can be accessed directly with it, like {input -> input.MyColumnName}
By default, columns defined from a concrete source table have the same name as the accessor used to get it. For example, qapi.tables().products().sku()
will lead to a column named "sku".
See PipelineStage
javadoc for a comprehensive documentation of each available stage. TODO link to the java doc.
Executing the query and fetching data
...