Semantics of Relationships and Operations
The following sections describe the semantics of relationships and operations that are possible with the types in CentraSite.
Association Relationship
Association relationships are the relationships that were available in later releases of CentraSite version 8 and are available with unchanged semantics in the current release.
Aggregation Relationship
The aggregation relationship changes the rules in the following way for operations:
Operation | Rules |
Delete an asset | There are no changes in the delete rules when introducing aggregation. |
Create a new version of an asset | There are no changes in the versioning rules when introducing aggregation. However, for assets of type Service and XML Schema, there is an additional possibility: If you select the check box Propagate to dependent objects when you create a new version of the root component of a composite asset of one of these types, the versioning is propagated also to components of these types that are connected to the root component through aggregation relationships. |
Set instance permissions on an asset | Merges the permissions of the initiating component with those of the current component. The permissions assigned to the contained component are the union of the permissions of the containing asset and the contained component. If the user that performs the operation does not have Full permissions on a component, then it and all of its sub-components is skipped. |
Move asset to another organization | There are no changes in the move organization rules when introducing aggregation. |
Change the owner of an asset | There are no changes in the change owner rules when introducing aggregation. |
Export an asset | If a component that has a containing aggregation is added to the export set, then the target is also added to the export set. The rules when selecting the check box Including instances in the user interface apply as before with the addition of the containing rules. |
Note:
For Export, the usage of recursive relationships on the type and instance level must be taken into account. Whereby type level does not mean that the same instance is referenced.
Composition Relationship
Composition relationships affect all the defined operations to varying degrees.
Operation: Deleting an Asset
On deletion, if the root component is added to the set to be deleted, then the sub-components is added to the set to be deleted. The direction of the association does not play a role in defining the set, only the containing designation. This means it is possible for the deletion to fail if one of the assets added to the deletion set during this processing is referenced through the basic association relationship target rules.
This rule is applied recursively. For example, if we have three assets that have the relationships, A contains B contains C, then the following statements apply:
When A is deleted, then B is deleted and finally because B is deleted, C is deleted.
When deleting C, only C is deleted.
This fails if the deleting user does not have permission on any of the assets in the set acquired by traversing the graph. The delete is considered atomic - either all are deleted or none. This avoids inconsistencies in the outcome of the operation.
The relationship direction always plays a role in the deletion operation. An asset may not be deleted if it is the target of a relationship and the source is not part of the deletion set.
The deletion rules described here apply also when you purge old versions of an asset. In this case, the purge operation will be applied not only to the component being purged, but also to the related sub-components.
Operation: Creating a New Version of an Asset
On versioning, if the root component is added to the set to be versioned, then the sub-components is added to the set. The direction of the association does not play a role in defining the set, only the containing designation.
If you create a new version of an asset that is the root component of a composite asset and the root component is related to one or more of the other components through composition relationships, CentraSite automatically creates a new version of each of these other components.
Operation: Exporting an Asset
On export, if the root component is added to the set to be exported, then the sub-component is added to the set. The direction of the association does not play a role in defining the set, only the containing designation.
Operation: Setting Instance Permissions on an Asset
On setting permissions, when the root component is added to the set to which the permissions is applied, then the sub-components asset are also added if and only if the user has the permission to modify the permission of the target. If the user does not have permission, then the graph traversal for the target is not carried further for this sub-graph.
The permission set that is given to all sub-component assets is the merge based on what is to be modified. The permissions assigned to the owned asset are the union of the permissions of the owning asset and the owned asset.
Operation: Moving an Asset to Another Organization
On moving an asset to another organization, when the root component is added to the set to be moved, then the sub-components are also added. No permission checks are done during this operation as only users in the CentraSite Administrator role may perform this operation.
Operation: Changing the Owner of an Asset
On changing ownership, when the root component is added to the set to be changed, then the sub-components are also added to the set. No permission checks are done during this operation as only users in the CentraSite Administrator role may perform this operation.