Artifacts Lifecycle

As part of a the API-refactoring, the lifecycle of Artifacts has been revisited. The existing API had evolved into a very complicated series of interactions between the Artifact Mgr and its clients.

Roles

• The Artifact Mgr holds the reference value of an Artifact and is responsible for persisting them
• Changes to artifacts can only occur in 2 ways:
  1. Getting a "working copy" of an artifact from the Art. Mgr., applying changes to it, and "committing" the changes on the working copy by providing it back to the art mgr.
  2. Submitting an IArtifactChangeRequest to the Art. Mgr.
• Each change will be made as atomic functions and automatically persisted
• The Art. Mgr. will use a defined persistence layer that is responsible to provide read/store mechanisms to the Art. Mgr.
• The Art. Mgr provides mechanisms to query models
• During a generation phase no changes on the model shall be permitted
• There is one Art. Mgr. per Tigerstripe project. It cannot be accessed directly but through a "session" through the project handle.
• Working copies of Artifacts need to optionally receive notifications that their original artifact has been modified in the Art. Mgr. Trying to commit a working copy that is "out-of-sync" should optionally raise an exception.

Use Cases