MetaDataSpec

Datasources

The reporting engine contains a datasource metadata layer. This layer allows datasources to provide additional formatting or processing information along with the bulk data.

DataSources provide MetaData by returning TableModels that implement the "org.pentaho.reporting.engine.classic.core.MetaTableModel". The Meta-Data is stored in DataAttributes, which are a map of <namespace,name> keys and arbitrary values.

DataSources can provide Metadata on three levels:

• ResultSet metadata via the "org.pentaho.reporting.engine.classic.core.MetaTableModel#getTableAttributes" method

Table/ResultSet-metadata should provide general information about the resultset, for instance details on the query, which database was used or whether the resultset is a remote object (and therefore expensive to access).

The following built-in datasources provide table-metadata:

• Column-specific metadata via the
  "org.pentaho.reporting.engine.classic.core.MetaTableModel#getColumnAttributes" method

This provides metadata that is the same for all columns, describing the column type, giving formatting information or telling how this column was created. The metadata provides for instance, hints on the Column-labels, provide user-friendly names for columns or give hints how the data in the columns should be formatted.

The following built-in datasources provide column-metadata:

• Cell-Metadata via the "org.pentaho.reporting.engine.classic.core.MetaTableModel#getCellDataAttributes" method

Cell-Metadata provides unique additional data for each of the cells in the resultset. This metadata allows the datasource to influence the formatting of certain cells based on the query. Right now, only the MDX-driven datasources can formula queries that create such cell-level attributes.

The following built-in datasources provide cell-metadata:

Datasource-Metadata Mapping

As each datasource has its own way to express metadata, the classic-engine metadata system does not try to force all metadata layers into one slim corset of predefined attributes.

The engine provides a well-known set of attributes along with strict syntax rules for these attributes. DataSources must map their proprietary metadata information into a own namespace to minimize collisions between the various metadata providers. The proprietary metadata can then be mapped into the well-defined attribute-set via mapping rules.

The mapping is implemented as DataSchemaDefinition", which is read and processed during the report processing. The mapping file contains rules that define how the proprietary objects created by the datasource should be processed to create objects the reporting engine can understand. The mapping does not prevent access to the raw-metadata that is available via the DataSources defined private namespace.

Functions and expressions can access the metadata through the ExpressionRuntime class.

User-Friendly names for Columns

Some metadata systems allow to hide the technical column names behind user-defined labels.

Fields, Expression and Functions that reference other columns from the datasource must always use the technical column name. Most metadata systems do not properly enforce uniqueness among the userfriendly names or even provide localized names. This makes it impossible to guarantee which column will be accessed during the report processing or makes columns unaccessible as soon as the processing happens in a different Locale setting.

Engine-level report objects must always reference technical columns and datasources must provide locale and runtime agnostic technical columnnames that allow a clean and unique mapping to column positions regardless of the current locale or similar settings.

The DataSchema-class provides access to all metadata settings, including the friendly names. Designtools that make use of the friendly names must ensure that the report-model is populated with technical names.