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

All workspace objects can be created at once via the Workspace Declarative Interface, while components of the analytics model can also be created individually via the Metadata Entity Interface.

Modify an object

All workspace objects can be updated at once via the Workspace Declarative Interface, while components of the analytics model can also be updated individually via the Metadata Entity Interface.

Delete an object

In general there are two ways how to delete object(s),

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 modifiedAt and 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, createdBy and modifiedBy are set to null, while createdAt and modifiedAt remain unchanged.

It is possible to change the createdAt, createdBy, modifiedAt, and modifiedBy properties using a PUT call in the declarative APIs. The following rules are followed by the API:

  • If neither createdAt nor createdBy is specified, the API will set createdAt to the time of the API call and createdBy to the user initiating the API call.
  • If createdBy is specified but createdAt is missing, or if modifiedBy is specified but modifiedAt is missing, the API will reject such requests.
  • In all other cases, the declarative APIs updates all relevant properties (createdAt, createdBy, modifiedAt, and modifiedBy) based on the provided payload.

For examples of declarative API calls, refer to the Extended Metadata section.

Objects Organization