AXIAM PHP SDK

ManagementManifest
in package

FinalYes

A declarative description of the state a tenant must be in (CONTRACT.md §27.6).

The whole point of the declarative layer is that a manifest says what must EXIST, not what to DO. The imperative surface ($client->management()->roles()->create(...)) is fine for one change; it is a poor way to describe a tenant, because re-running it either fails on the second run or requires the caller to hand-write the "does it exist already?" logic for every object. A manifest is re-runnable by construction: apply it twice and the second run sends nothing.

Two properties are worth stating because they constrain everything else:

  • Omission is never deletion. A tenant holds objects this manifest does not mention, and they are left strictly alone.
  • Ordering is DERIVED, not declared. The caller does not sequence anything; see ManifestKind and self::ordered().

Table of Contents

Properties

$entities  : array<string|int, mixed>

Methods

__construct()  : mixed
builder()  : ManifestBuilder
A fluent builder — the usual way to construct one by hand.
ordered()  : array<int, ManifestEntity>
The entities in apply order: by kind, then by an explicit dependency sort within each kind, then by key.

Properties

Methods

ordered()

The entities in apply order: by kind, then by an explicit dependency sort within each kind, then by key.

public ordered() : array<int, ManifestEntity>

The final tie-break on $key is what makes a plan STABLE ACROSS RUNS (§27.6). Two entities of the same kind with no dependency between them have no natural order, and without a deterministic tie-break they would come out in whatever order the declaration happened to be built in — making every plan diff unreadable.

Tags
throws
ManifestException

when a dependency is dangling or circular.

Return values
array<int, ManifestEntity>
On this page

Search results