...
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.
Dataschema mappings
Dataschema mappings are rules that define metadata attributes or translate metadata attributes from proprietary systems like Pentaho Metadata or MDX-Attributes into the engine's preferred metadata style.
Pentaho Reporting uses a simple metadata system. Metadata is stored as map of <(namespace, name), (value)> on the various dataitems. Metadata can be given on a global level, column-level (PMD) or cell-level (for example MDX attributes).
The values are always primitive objects, so that they can be used in computations more easily. Limiting ourselves to the most simple objects also serves as common denominator between all metadata systems out there. This keeps the system open to accept bindings from all metadata systems, as long as they provide a Java-API.
Metadata is provided by JDBC, MQL and Mondrian/OLAP4J datasources. In addition to that, parameters and expressions provide some primitive hooks into the metadata system as well (mainly to serve as matching parameters for the rules).
There are only two mapping types:
- Global mappings
These are always applied unconditionally.
This is primarily used to define mappings from one meta-system to another or to define global attributes that are always set on all columns. The main use-case for that is to provide administrators a way to inject well-known global attributes to the system that can be used in formulas.
- (in)direct-mappings
A mapping that is applied if a given rule is matched. A rule can be either that a given attribute is defined (and can have any value) or that it is checked whether a attribute matches the given value.
Direct-mappings are a special case with a rule searching for field-names only. A direct-mapping is the same as a indirect-mapping searching for (core::fieldname) with the given fieldname value.
These mappings serve two purposes. Again they can be used to map attributes from one meta-system to another, but this time the mapping is conditional, which allows some more sophisticated rules.
And finally, they can be used to enrich the existing metadata with additional values, as some sort of lightweight metadata system.
On each mapping type, we provide the option to either add static attributes or to map (and possibly convert) attributes from one metadata attribute to another. As every metadata system comes with its own object model, we use "ConceptQueryMapper" to convert metadata-objects into their canonical form.
Right now, there are two ways to use the metadata in the reports:
- Auto-apply some well-known metadata attributes as style and element-attributes via the "MetaDataStyleEvaluator"
This reads the values for "font-bold", "font-italic", "font-strikethrough", "font-underline", "font-size", "font-family", "background-color", "color", "horizontal-alignment" and "vertical-alignment" as style information.
The "format-string" and "label" of a column can also be applied.
- Use the metadata in a formula via the "METADATA(<column>, <namespace>, <name>)" formula-function or Use the metadata in a Java-Expression/Function via "ExpressionRuntime#getDataSchema"
In its current state, the metadata-mapping system is not exposed to the common user. Mapping rules can be stored in the bundle, but we do not provide a UI for that in Citrus.
For Citrus, mappings are aimed at data-source implementers and administrators who want to make custom PMD attributes available in the reporting system or who want to create sensible defaults for non-PMD datasources. These folks should know how to use an XML editor and can use the
report-configuration to bind the dataschema files to the engine.