Overview

Data Query turns a stored query into a complete reporting screen. An administrator defines a query once — its text, the parameters it accepts, and the columns it returns — and the appjar builds the rest: a parameter form, a lazy-loaded results grid, sorting and per-column filtering, data export, an optional chart, and links that carry the values of a row into another query. No Java code and no redeploy are needed to publish a new report.

The problem it addresses is a recurring one in enterprise applications. Users ask for a report; the report needs one more column, or a different date range, or a breakdown by another dimension. Each request becomes a view, a service method, a query, and a release. Data Query moves that cycle out of the development pipeline and into a management screen, while keeping the two things that must not be delegated — the query text and the shape of the result — under the control of an administrator rather than an end user.

Queries, parameters and result columns

A query definition is the central concept. It names a data source connector, holds the query itself, and declares two lists: the parameters it accepts and the result columns it produces.

Parameters are typed, so the parameter form renders the right field for each one — a date picker for a date, a combo box for an enumerated list, a multi-select for a value used in an IN clause. A parameter can carry a fixed default, or delegate its default to a value generator that resolves at the moment the form opens: the current date, the current user, or the values of a column of another query.

Result columns describe the output rather than deriving it. Each one declares a type, an optional display format, and whether it can be sorted, filtered or hidden. That declaration is what lets the same query drive a grid, a chart, a spreadsheet export and a printed report without any of them needing to know where the data came from.

Three data sources

Not every report reads the application's own database, so the query text is interpreted by a connector chosen per query.

The SQL connector runs the statement against the application's JDBC data source. It is the right tool when a report has to reach tables the application does not map, or when the report needs SQL that no object-relational mapping can express.

The HQL connector runs the statement through the application's own persistence layer, so the author writes entity and attribute names instead of physical table and column names. The mapping becomes the single source of truth, and because the persistence metamodel is available while the query is being written, the editor offers real code completion over the application's entities and their attributes.

The REST API connector issues an HTTP request and turns the JSON response into rows. This is how data that lives in another system enters a report at all.

Whichever connector answers, the result has the same shape. That is the point of the arrangement: the grid, the charts, the exporters, the printed reports and the dashboard widgets all work identically for all three.

Chaining queries

A single query is not always enough. A report may need data from an external service joined against local tables, or an expensive intermediate calculation reused by a later step.

A query can therefore depend on other queries. Dependencies run first, in a declared order, and a dependency can write its results into a temporary table that a later query reads like any other table. Parameters are forwarded from the query the user opened down to its dependencies, so an entire chain is driven by the single parameter form the user sees. Temporary tables are scoped to one execution and removed when it ends, so concurrent users never collide.

Charts, drill-down and dashboards

A query's results can be drawn as a chart — bar, horizontal bar, line, area, pie, donut or scatter — by mapping result columns onto chart roles such as category, value and series. The underlying grid remains available beside the chart.

Both grids and charts support drill-down: a result column can be rendered as a link, and a chart element can be made clickable, with values from the clicked row or bar passed as parameters to a target query. Chaining these links produces a path from a summary to its detail without a line of navigation code.

Dashboards compose several queries onto one page. Each widget points at a query definition, renders it as a grid or a chart, and supplies its parameters from stored values or value generators, so a dashboard shows data immediately with no form to fill in. Widgets are arranged by dragging and resizing them, and each dashboard is published at its own address.

Printed reports

A grid export is enough for a spreadsheet, but not for a document that has to be laid out precisely. A query definition can therefore carry an optional report template, drawn in a built-in visual designer: a canvas of bands — title, page header, detail, group header and footer, page footer — onto which text, fields, images, lines and shapes are placed.

The template never defines its own data. Its fields are the query's result columns and its parameters are the query's parameters, so it is filled with exactly the rows the user is looking at, using exactly the parameter values and column filters they entered. When an enabled template exists, the report view's export produces a PDF rendered from that layout; without one, the standard grid export applies.

Multilingual texts

The names an administrator types — a query's display name, a category's name, a dashboard's title, a chart's heading — are stored as literal text and shown as typed. An application served in several languages can instead mark a query, category or dashboard as internationalised, which reassigns those fields: they then hold translation keys, resolved for the language of each user. Where the translations live is the application's decision; an application that also installs the I18N Manager appjar can manage them from its UI.