Typeful Metadata

[homedirectory]

Description

Completing the transition from EQL2 metadata to EQL3 metadata has posed some challenges due to
structural differences between the two. In particular, EQL3 metadata is less rich than its
predecessor, which requires its users to perform ad-hoc computations to retrieve the needed
information (e.g., to check whether a property represents a composite key), ultimately decreasing
the usefulness of the abstraction.

Historically, EQL metadata has been modelled with a simple abstraction -- a bag of attributes, i.e.,
a single Java class with multiple null-able fields.
For example, metadata for entity properties has been modelled with a single class that has both
column and expressionModel fields with the former indicating a persistent nature and the latter
-- a calculated one. Since a property may have only one nature, only one of these fields may have a
non-null value in any given instance.

While such a simple abstraction may have been sufficient previously, the evolution of TG and its
modelling capabilities requires a more powerful abstraction to tackle the growing complexity.
Therefore, a typeful model for EQL metadata is proposed. Such model is based on the use of type
information, and provides stronger guarantees in the form of static properties of the program.
This model heavily relies on typechecking, which the Java compiler provides. Some of the
advantageous features supported by Java 21 are: sealed classes (can be used to model ADTs) and
pattern matching.

In a typeful model, types are used to represent domain concepts. In this case the primary concepts
are entities and their properties, which can be classified into several categories and modelled with
types accordingly (consult the TG Wiki for details).

Expected outcome

Typeful metadata abstraction is introduced to assist with completing the migration to EQL3 metadata.

Implementation

Inspiration can be drawn from the mirror-based API for Java annotation processing (javax.lang.model),
which has separated types into 2 levels: elements (TypeElement) and types (TypeMirror). The
same could be applied to TG metadata: elements -- entity and composite type definitions, types -- property types.
The latter (types) use the former (elements) and optionally include annotations for the purpose of
refinement. For example, numeric types can be refined by specifying their precision and scale.