Store

Information

Dies ist die Dokumentation des alten Stores der in v4.0 entfernt wird. Für den neuen Store, der in v3.5 eingeführt wurde, siehe Store (neu). Für Hilfe bei der Migration, siehe Aktualisierung.

Der Store enthält Konfigurationsobjekte.

Konfiguration

Option	Typ	Default	Beschreibung
mode	enum	READ_WRITE	READ_WRITE oder READ_ONLY. Bestimmt ob die Applikation Änderungen am Store vornehmen darf.
additionalLocations	array	[]	Deprecated Liste von Pfaden mit zusätzlichen Verzeichnissnen.

Struktur des Store

Jedes Konfigurationsobjekt hat einen Typ, einen optionalen Sub-Typ sowie eine für den Typ eindeutige Id (siehe Konfigurationsobjekt-Typen). Der Pfad zur entsprechenden Konfigurationsdatei sieht dann so aus:

store/entities/{typ}/{id}.yml

Defaults für alle Konfigurationsobjekte eines Typs oder Sub-Typs können optional in solchen Dateien gesetzt werden:

store/defaults/{typ}.yml
store/defaults/{typ}.{sub-typ}.yml

Außerdem kann man noch Overrides für Konfigurationsobjekte anlegen. Diese haben z.B. den Zweck, umgebungsspezifische Anpassungen vorzunehmen, ohne die Haupt-Konfigurationsdateien ändern zu müssen. Der Pfad zu den Overrides sieht so aus:

store/overrides/{typ}/{id}.yml

Defaults, Konfigurationsobjekte und Overrides werden in dieser Reihenfolge eingelesen und zusammengeführt. Das heißt Angaben im Konfigurationsobjekt überschreiben Angaben in Defaults und Angaben in Overrides überschreiben sowohl Angaben in Defaults als auch im Konfigurationsobjekt.

Das Zusammenführen funktioniert auch für verschachtelte Strukturen, d.h. man muss in den verschiedenen Dateien keine Angaben wiederholen, sondern kann z.B. in Overrides nur gezielt die Angaben setzen, die man überschreiben will.

Die zusammengeführten Konfigurationsobjekte müssen dann alle Pflichtangaben enthalten, ansonsten kommt es beim Start zu einem Fehler.

Zusätzliche Verzeichnisse

Bei fest vordefinierten oder standardisierten Konfigurationsobjekten kann es Sinn machen, umgebungsspezifische Anpassungen in einem separaten Verzeichnis vorzunehmen. Ein oder mehrere solche Verzeichnisse können mit additionalLocations konfiguriert werden. Die anzugebenden Pfade können entweder absolut oder relativ zum Daten-Verzeichnis sein, also z.B.:

store:
  additionalLocations:
    - env/test

Ein solches Verzeichnis kann dann wiederum Defaults und Overrides enthalten, also z.B.:

env/test/defaults/{typ}.yml
env/test/overrides/{typ}/{id}.yml

Die Reihenfolge der Zusammenführung für alle aufgeführten Pfade sähe dann so aus:

store/defaults/{typ}.yml
store/defaults/{typ}.{sub-typ}.yml
env/test/defaults/{typ}.yml
store/entities/{typ}/{id}.yml
store/overrides/{typ}/{id}.yml
env/test/overrides/{typ}/{id}.yml
``
     

## Aufsplitten von Defaults und Overrides     

Defaults und Overrides können in kleinere Dateien aufgesplittet werden, z.B. um die     Übersichtlichkeit zu erhöhen. Die Aufsplittung folgt dabei der Objektstruktur in den     Konfigurationsobjekten.     



```yml

key1:
  key2:
    key3: value1

Um ein Default oder Override für diesen Wert zu setzen, könnten die oben beschriebenen Dateien verwendet werden:

store/defaults/{typ}.{sub-typ}.yml
store/overrides/{typ}/{id}.yml

Es können aber auch separate Dateien für das Objekt key1 oder das Objekt key2 angelegt werden, z.B.:

store/defaults/{typ}/{sub-typ}/key1.yml

key2:
  key3: value2

store/overrides/{typ}/{id}/key1/key2.yml

key3: value3

Der Pfad des Objekts kann also sozusagen aus dem YAML ins Dateisystem verlagert werden.

Die Reihenfolge der Zusammenführung folgt der Spezifität des Pfads. Für alle aufgeführten Pfade sähe dann so aus:

store/defaults/{typ}.{sub-typ}.yml
store/defaults/{typ}/{sub-typ}/key1.yml
store/entities/{typ}/{id}.yml
store/overrides/{typ}/{id}.yml
store/overrides/{typ}/{id}/key1/key2.yml

Es gibt einige Sonderfälle, bei denen das Aufsplitten nicht nur anhand der Objektpfade erlaubt ist, sondern z.B. auch für eindeutig referenzierbare Array-Element. Auf diese Sonderfälle wird in der Beschreibung der Konfigurationsobjekt-Typen im Abschnitt "Besonderheiten" eingegangen.