Page History
| Info | ||||
|---|---|---|---|---|
| ||||
Aggregates are used for storing a snapshot of the profile or a part of the profile, that can be read, updated and/or deleted across sessions. You might compare it to the way information in a NoSQL database is stored. Avoid using aggregates in the same way tables in an SQL database are used. |
What is it?
A set of entities can be declared as an aggregate. This means that they belong together and should always be stored and loaded together. Only the user-set values of attributes and relations are stored.
...
Shown below is the aggregate definition of an aggregate PersonAggregate. The definition only contains the entity Person, but in fact all Jobs that this Person has are part of the aggregate as well. Instances of the relation HasJobs are used and stored as a connector between the instance Person and the instances of Job.
What does it do?
Where an entity divides the main model into main ‘subjects’, an aggregate groups some of these main subjects together into a coherent set. These entities can be added using the +Add entity button. Remove unwanted relations (and connected entities) from the aggregate definition using the toggle. The list of included relations is updated after each toggle update.
| UI Text Box | ||
|---|---|---|
| ||
Please note that any relations to instances that do not belong to the aggregate are cleared, and are not recreated when loading the aggregates. |
Custom metadata
In the Custom metadata section, custom metadata can be specified for an aggregate using expressions.
...
| UI Text Box | ||
|---|---|---|
| ||
You may be tempted to add as much metadata to an aggregate as possible, as these can be shown in lists later on. We strongly advice against adding metadata only for 'just in case'. Each metadata attribute creates an entry in the database when an aggregate is stored. The more metadata fields are added, the quicker entries are made in the database which at some point may impair the performance. Therefore, we advise the following:
Please see Runtime performance reports for how we test the performance of our reference application. |
Roles
In the properties panel, the authorization on aggregates can be configured. The roles you set are authorized to perform operations on aggregates of this type. When a role is authorized, a user with that role is able to create, read, update and delete aggregates of this type. It is not possible to make this authorization more specific, e.g. to only allow read access. If there are no roles configured on an aggregate, then everyone is authorized.
...
More about aggregates and persistency management in the Persistency Management guide.
Creating, reading, updating, deleting, searching and counting (CRUD-SC)
Aggregates are managed using the following service calls:
...
Each aggregate has an ID (part of the default metadata) that uniquely identifies the aggregate. When creating (=storing) or searching for an aggregate, its ID is saved into a selected attribute. Read, update and delete operations then use this attribute to identify which aggregate to perform the operation on.
Showing aggregates
A list of aggregates (that is, a list of instances of an aggregate type) can be shown on a page by using the Container type: AQ_Aggregate_List. This container can show metadata (standard and custom), filter on metadata, and show buttons to act on one particular aggregate.
...
Overview
Content Tools