blob: 726c2d568f34cbfa3f7f3c38a8b586e6d76bb973 [file] [log] [blame]
<h1>Artifacts Lifecycle</h1>
<p>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.</p>
<h2>Roles</h2>
<ul>
<li>The Artifact Mgr holds the reference value of an Artifact and
is responsible for persisting them</li>
<li>Changes to artifacts can only occur in 2 ways:
<ol>
<li>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.</li>
<li>Submitting an IArtifactChangeRequest to the Art. Mgr.</li>
</ol>
</li>
<li>Each change will be made as atomic functions and automatically
persisted</li>
<li>The Art. Mgr. will use a defined persistence layer that is
responsible to provide read/store mechanisms to the Art. Mgr.</li>
<li>The Art. Mgr provides mechanisms to query models</li>
<li>During a generation phase no changes on the model shall be
permitted</li>
<li>There is one Art. Mgr. per Tigerstripe project. It cannot be
accessed directly but through a "session" through the project handle.</li>
<li>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.</li>
</ul>
<h2>Use Cases</h2>
</p>