Workspace Objects Life Cycle
Every object have its ordinary life cycle beginning with creation and ending with deletion. In between these states the object might be modified multiple times and even deleted-recreated. These objects interact with other objects in their specific way and especially deleting of an object might have negative impact on an end user experience and usability of the platform.
graph LR create --> modify create --> delete modify --> delete delete --> recreate recreate --> modify
Create an object
Modify an object
Delete an object
In general there are two ways how to delete object(s),
- indirectly - that applies to any workspace object (set of objects) by not sending them back via the Workspace Declarative Interface,
- directly - that applies to components of the analytics model only via the Metadata Entity Interface.
Details of the indirect delete procedure
When using declarative interface then all objects including their relations must be valid, ie. point to an existing object, otherwise the change won’t be accepted by server. On the other hand it is possible to use declarative interface for the logical model, and the analytics model separately. Replacing analytics model won’t cause any issue, while the new layout will be accepted with valid objects/relations only. Replacing logical model only might cause deleting of relations to objects from the analytics model, and these objects might not be usable for further computing, some details on this topic can be found in the Workspace Declarative Interface.
Details of the direct delete procedure
Objects can be directly deleted from the analytics model only. When an object is deleted, then its relations to other objects are deleted too, so affected objects can’t see / include these objects anymore. Contrary objects that referenced the deleted object still contain definition of relation to the deleted object. Such object can be retrieved from server, but can’t be putted back until no longer valid references are removed or replaced by valid one.
Impact of deleted objects
When as a result of deletion remains in platform objects with no longer valid references, then you will face following inconveniences:
The output of the Workspace Declarative Interface will contain objects with no longer valid references, that is, you can download the workspace model, but you can’t put it back until all invalid references are removed or replaced.
Objects with no longer valid references (or more precisely with references to either non-existing or themselves invalid objects) won’t be listed in
GoodData.UI. Still they can be accessed via the Metadata Entity Interface.
Recreate an object
It is possible to delete an object while keeping analytics objects originally referencing deleted object untouched in terms of their definition. Therefore, one can assume that creating the object with identifier of deleted object again will restore the state of objects to state before deleting. That is true just partially, it will be possible to start report computing again, but retrieving the object including relations won’t work. Restoring of an object won’t restore lost relations, this can be achieved by putting back the whole analytics model via the Workspace Declarative Interface.
Object Authors and Editors
Analytical entities, such as analytical dashboards, dashboard plugins, visualizations, and metrics, carry the following metadata concerning their creation and the most recent edits:
createdBy: Records the entity’s creator.
createdAt: Marks the timestamp of entity creation.
modifiedBy: Records the user responsible for the most recent modifications.
modifiedAt: Marks the timestamp of the last edit.
If a new object is created, the
createdAt property is automatically set to the current server’s local time, and
createdBy is assigned to the user who created the object. In cases where an object is modified using PUT or PATCH operations, the
modifiedBy properties are updated to reflect the user and time of the API call, respectively.
These properties are associated with user references. Because of that, if a user is removed from the organization,
modifiedBy are set to null, while
modifiedAt remain unchanged.
It is possible to change the
modifiedBy properties using a PUT call in the declarative APIs. The following rules are followed by the API:
- If neither
createdByis specified, the API will set
createdAtto the time of the API call and
createdByto the user initiating the API call.
createdByis specified but
createdAtis missing, or if
modifiedByis specified but
modifiedAtis missing, the API will reject such requests.
- In all other cases, the declarative APIs updates all relevant properties (
modifiedBy) based on the provided payload.
For examples of declarative API calls, refer to the Extended Metadata section.