Synthetic entities

Synthetic entities provide a way to implement the "informative function" of Information Systems and can aggregate data from other synthetic entities or persistent entities.

Entity IDs

In the most general case, synthetic entities do not have an ID associated with them. This is only natural as aggregated data simply does not have a corresponding record in the database, which would have an ID. However, there is one case where ID can be derived and be used to provide additional functionality. Specifically, where a synthetic entity does not aggregate the data, but rather provides additional information on top of one or more persistent entity types.

For persistent entities property id is fetched by default every time they are read from a database. Due to the intrinsic nature of synthetic entities fetching id by default is not possible. So, the platform tries to be smart where it can to dynamically identify cases where automatic fetching ofid is possible. In other cases, the developers need to do some manual transformation to ensure that id values are present.

Before discussing these two cases, it is important to emphasise that yielding some property when constructing an underlying EQL model for some synthetic entity, does not mean that property will be fetched. The fetch model controls what is actually read from the database, while yield only defines what is available for fetching.

Automatic fetching of id

There are two situations where automatic fetching of id happens for synthetic entities:

1. Synthetic entity has a key type, which is a persistent entity.

2. Synthetic entity extends a persistent entity. yieldAll() should be used in the underlying EQL model in this case to avoid enumeration of all inherited properties for yielding manually.

In all other situations id is not fetched.

Manual transformations for id fetching

There potentially many different situations where id values can be derived manually. This subsection describes two situations where the base model for a synthetic entity effectively represents a sum type (either one or another [or another...] type). And although on the surface these situations are different, they boil down to the same transformation technique.

A good example for the first situation is from the TG Air domain -- synthetic entity Manpower. Each instance of this entity could be based on either persistent entity Team or Person. In this case, the key for such synthetic entity Manpower is composite, consisting of an instance of either Team or Person (although, this is not important).

Because, every instance of Manpower has a persistent entity with id as its basis (Team or Person), it is possible to derive id for instances of Manpower. However, this is a very specific case and the platform does not handle it at the moment. Hence, no automatic fetching of id.

This is where the power of transformation comes handy. Here are the steps:

1. Define property computedId: Long as part of a synthetic entity.
2. Override getter getId() to return computedId.
3. Yield both id and computedId as part of the underlying EQL model.

The above recipe will ensure that such synthetic entities can be correctly represented in the Entity Centre, selected entries can be exported to Excel and even the type-specific Entity Masters can be invoked for them.

Another situation, which boils down to the one above, is where several persistent entity types with a common base type are used for defining an EQL model that underpins a synthetic entity. A good example of this from the TG Air domain is entity EscCoc with an EQL model, which is based on four (4) sub-model.

Each of those sub-models is based on a separate persistent entity type. And because of that, the values for id can be derived for each sub-model and by extension for each instance of EscCoc. In order to achieve this the steps described above should be used.

N.B. In order for id to be included as part of synthetic entities that are displayed on their corresponding Entity Centres, the centres need to be configured to include this. However, if adding this is inappropriate then simply extending the default fetch model with id is the best way. For example,

// as part of Entity Centre configuration
.setFetchProvider(fetchNone(EntityType.class).with("id"))