Sub search
Restrictions – Abstract
Purpose: As a restriction, a Sub search checks whether at least one instance exists for the selected Entity that fulfills the configured Where condition.
As a restriction, a Sub search checks whether at least one instance exists for the selected Entity that fulfills the configured Where condition.
In the same way as the Subsearch projection, a Tuple search can be formally configured with a single Projection, which can also contain Joins and criteria for a Group by.
Projections within the Sub search primarily refer to the Entity selected for the Sub search as the data source.
The _parentQuery prefix enables references to the parent search. It can be cascaded if required (_parentQuery._parentQuery.[...]) to address a specific level of a multi-level hierarchy.
In contrast to a Subsearch projection, however, the Sub search, like all other Restrictions, only returns a Boolean return value and does not provide any details about the search result or the value of any configured Projection:
The return value is true if at least one instance exists for the Entity that fulfills the Where condition.
The return value is false if no instance exists for the Entity that fulfills the Where condition
►IMPORTANT◄ The Sub search ignores access restrictions. It considers all instances of the selected Entity regardless of ownership, participation or Company authorizations.
Configuration
|
Parameter |
Type |
Description |
|
Entity |
Entity type |
The selection for the Entity parameter determines the primary data source for the Sub search. Only the entity types offered in the dropdown can be selected. Entity types that are not directly available as an 'Entity' in the parent search (e.g. attributes) can also be selected for a Sub search. ►NOTE◄ Additional data sources can optionally be integrated into the Sub search via Joins. |
|
Projection |
Projection |
The configuration of a Projection can be dispensed with, as only the existence of a "result line" is decisive for the Sub search as a restriction.
|
|
Joins |
Join |
Additional data sources can be added to the Sub search via Joins, which are then available for Projektionen in other areas within the Sub search. |
|
Where |
Restriction |
The Where parameter enables the configuration of Restrictions for the acceptance of instances of the Entity within the Sub search.
|
|
►IMPORTANT◄ If the configuration of a Where condition is completely omitted in the context of a Sub search, then the Sub search is completely ignored when compiling the database query. |
||
|
Group by |
Projection |
The configuration of criteria for a Group by does not generally represent any added value for the effect of a Sub search as a restriction, as this only checks the existence of at least one result row. |
Examples
Simple use case: Recognize orphaned weak references
A 'weak reference' is a reference to entities whose existence is not considered an obstacle to the deletion of the entity in question.
For example, all entities use a 'weak reference' to refer to the ID (id) of a company account via the 'owner' (ownerId) property. A company account that 'owns' other entities can therefore be deleted without the owned entities first having to be assigned to a new owner.
A Search should list Users for whom the company account referenced as 'owner' (ownerId) no longer exists.
Configuration:
|
In a Search for Users, the Where condition is configured as an AND conjunction as shown on the right:
Effectively, the Where condition of the parent search is passed if the 'owner' property of the user account specifies an ID for which the Sub search does not find a match among all company accounts. As the Sub search ignores any access restrictions, this implies that the company account referenced as the 'owner' does not exist (anymore). |
|
Typical use case: Incoming reference(s) as a restriction
A custom overview (see Custom overviews) should only list those Users to whom at least one document (see Documents) with the Document type 'CV' (CV) is assigned.
►NOTE◄ Assigned Documents refer to the 'referenced object' and not vice versa (see Assigning documents). Therefore, the properties of all Documents relevant for the reference must be evaluated in order to identify 'assigned documents'.
Configuration:
|
A Sub search is configured as a Restriction for the custom overview as shown on the right:
|
|
|
|
|
►NOTE◄ If access restrictions are effective in the execution context, the custom overview only takes into account Users for whom read access is granted. Accordingly, the incoming references of documents are only checked for these users. Whether there is access to the 'qualifying' CV document in the execution context is not decisive, as the Sub search ignores access restrictions. The overview may therefore also show user accounts for whose 'CV' document there is no read access.
Special use case: Identifying duplicates
A Search should list all Company accounts whose address uses an 'account number' (address.accNumber) that is 'ambiguous' – i.e. also assigned to at least one other company.
Configuration:
|
Within a Search for Company accounts, a Sub search is configured as the only restriction in the Where condition, as shown on the right:
►NOTE◄
|
|
►NOTE◄ In an execution context with effective access restrictions, the Search returns all Firme whose 'account number' is assigned ambiguously AND for which read access exists. Therefore, the search result does not necessarily always show all Company accounts that refer to the same ambiguously assigned account number, but only those for which read access also exists in the execution context. Overlaps between the account numbers of Company accounts for which there is no read access in the execution context are not evaluated