Workflow/tasks/cache_schreiben.md

cache_schreiben — Datei-Cache schreiben

Zweck: Legt Daten unter dem MD5 des Anfrage-Schlüssels ab (gleicher Schlüssel wie bei cache_lade → gleiche Datei). Typischer Einsatz: nach einer teuren Live-Ladung (geo_wfs, KI, ogr2ogr) das Ergebnis cachen, damit die nächste Ausführung es aus cache_lade bekommt.

Gegenstück: cache_lade.

Parameter

Name	Pflicht?	Default	Beschreibung
schluessel	ja	—	Identisch zu cache_lade (→ gleiche Datei).
daten	ja	—	Zu cachender Inhalt, z.B. {{gem_geojson}}. Leere Daten werden nicht gecached (schützt vor Caching fehlgeschlagener Ladungen).
namensraum	nein	—	Optionaler Unterordner ([a-z0-9_-]).
roh	nein	0	0 = HTML-Entity-Decode vor dem Schreiben (" → "), damit echtes JSON gespeichert wird — symmetrisch zu geo_json_parse. 1 = exakt so speichern, wie gerendert.
output_var	nein	cache	Präfix der Meta-Ausgaben.

Ausgangswerte

Variable	Beschreibung
{{<prefix>_ok}}	1 = geschrieben, 0 = leer/übersprungen.
{{<prefix>_key}}	MD5 des Schlüssels.
{{<prefix>_bytes}}	Geschriebene Byte.
{{<prefix>_pfad}}	Cache-Dateiname (relativ).

Beispiel

<task type="cache_schreiben" id="gemeinden_cache_write">
  <config>
    <schluessel>gemeinden|{{umring_bbox}}|5000</schluessel>
    <daten>{{gem_geojson}}</daten>
    <namensraum>gemeinden</namensraum>
    <output_var>gemcachew</output_var>
  </config>
</task>

Hinweise

• Escaping-Falle: {{var}} wird von Mustache HTML-escaped (" → "). cache_schreiben decodiert das per Default zurück (roh=0), damit gültiges JSON im Cache liegt. cache_lade liefert die Rohbytes zurück; beim Einspeisen in den nächsten Task escaped Mustache wieder → geo_json_parse decodiert erneut. Der Cache-Pfad verhält sich damit identisch zum Live-Pfad.
• Atomar geschrieben (Temp-Datei + rename), d.h. keine halben Dateien bei parallelen Läufen.
• Ablaufsteuerung passiert in cache_lade per ttl — cache_schreiben selbst kennt keine Lebenszeit (schreibt nur erstellt).