14.2.3. The dynamics of state change

Contexts and roles that are created, are immediately cached. However, we do not always immediately save them to Couchdb. This is because sometimes, after initial creation, resources have to be changed. Think of a context instance: we prefer to wait until all its roles have been created, before we save them. This is because we may yet encounter an error while working out the roles. Instead of retracting prematurely saved roles, we wait with saving them until the entire process has been finished without errors.

For similar reasons we do not immediately dispatch a Transaction as soon as a change has been cached or saved.

14.2.3.1. Creating and modifying resources

There are no more than two modules where instances are created:

  • Perspectives.BasicConstructors, with the functions

    • constructContext and

    • constructAnotherRol

  • Perspectives.LoadCRL

There is a single module through whose functions all changes to resources run:

  • Perspectives.Assignment.Update

In turn, all these functions are used in two distinct places:

  • Perspectives.Api

  • Perspectives.Actions

The first module channels resource creation and modification that are the initiative of the end user. The second module realises the automatic execution of such actions by bots.

The consequence is that all caching, saving and synchronising starts in the above three modules.

14.2.3.2. Saving and syncing resources

The module Perspectives.SaveUserData contains five functions to save cached Context- and Role instances and to synchronise them:

  • saveContextInstance (to used in tandem with constructContext)

  • saveRoleInstance (idem, constructAnotherRol)

  • removeContextInstance

  • removeRoleInstance (to be used in tandem with removeRol)

  • removeAllRoleInstances (to be used in tandem with deleteRol and setRol)