3.4 KiB
Executable File
cache_lade — Datei-Cache (Lookup oder Container)
Zweck: Prüft, ob zu einem Anfrage-Schlüssel bereits ein (noch gültiger) Cache existiert. Der Schlüssel wird per MD5 zum Dateinamen, ttl (Sekunden) steuert die Lebenszeit.
Zwei Betriebsarten:
A) Container (empfohlen — wie if)
cache_lade enthält Kind-Tasks. Bei Hit werden die Kinder übersprungen und {{ziel_var}} kommt sofort aus dem Cache. Bei Miss laufen die Kinder (sie laden die Daten live in {{ziel_var}}), danach wird {{ziel_var}} automatisch gecacht. Ein Task — kein separates cache_schreiben, kein if.
B) Lookup (ohne Kinder)
Setzt nur {{<prefix>_treffer}} (1/0); die Live-Ladung macht der Workflow selbst (z.B. per type="if"). Gegenstück dann: cache_schreiben.
Parameter
| Name | Pflicht? | Default | Beschreibung |
|---|---|---|---|
schluessel |
ja | — | Anfrage-String → MD5-Dateiname. Alle variablen Teile aufnehmen, z.B. gemeinden|{{umring_bbox}}|5000. |
ttl |
nein | 0 |
Lebenszeit in Sekunden. 0 = unbegrenzt. Älter → Miss (Datei wird gelöscht). |
ziel_var |
nein¹ | — | Variable mit den Daten. Hit → wird gesetzt; Container-Miss → wird nach den Kindern daraus gecacht. Sinnvoll = Ausgabe-Var des Live-Loaders (z.B. gem_geojson). |
namensraum |
nein | — | Unterordner ([a-z0-9_-], max 64). |
output_var |
nein | cache |
Präfix der Meta-Ausgaben. |
¹ Im Container-Modus Pflicht (legt fest, was gecacht/ausgegeben wird).
Kind-Tasks (Container)
Direkt als <task>-Kinder von cache_lade (wie <then> bei if, nur ohne Wrapper). Sie werden nur bei Miss ausgeführt und müssen {{ziel_var}} befüllen. Auch wartende (interaktive) Kind-Tasks funktionieren — der Workflow setzt beim nächsten Trigger an derselben Stelle fort.
Ausgangswerte
| Variable | Beschreibung |
|---|---|
{{<prefix>_treffer}} |
1 = kam aus Cache, 0 = frisch geladen (oder Lookup-Miss). |
{{<prefix>_key}} |
MD5 des Schlüssels. |
{{<prefix>_alter}} / _bytes / _erstellt |
nur bei Hit. |
{{<prefix>_daten}} |
die gecachten Daten (nur Hit). |
{{<prefix>_ok}} |
1 = im Container-Miss frisch gecacht. |
{{<ziel_var>}} |
= Daten (Hit; im Container auch nach der Live-Ladung gesetzt). |
Muster: Gemeinden nur einmal laden (Container)
<task type="cache_lade" id="gemeinden_cache">
<config>
<schluessel>gemeinden|{{umring_bbox}}|5000</schluessel>
<ttl>604800</ttl> <!-- 7 Tage -->
<ziel_var>gem_geojson</ziel_var>
<namensraum>gemeinden</namensraum>
<output_var>gemcache</output_var>
</config>
<task type="geo_wfs" id="gemeinden_laden">
<config> … <output_var>gem</output_var> </config> <!-- setzt gem_geojson -->
</task>
</task>
<!-- ab hier ist {{gem_geojson}} gesetzt — egal ob Cache oder live -->
Hinweise
- Der
schluesselmuss bei Wiederholungen identisch sein (gleiche MD5-Datei). Ablage:0_workflow/cache/[<ns>/]<md5>.cache(JSON-Envelope miterstellt+daten). - Container cacht
context[ziel_var]direkt (echte Bytes) — keine Escaping-Sonderbehandlung nötig (anders alscache_schreiben, dessendatenper{{…}}gerendert und daher entity-dekodiert wird). - Verifiziert (VKZ 22047, fb-gemeinden): kalt 1,87 s (Miss → WFS + Auto-Cache, 707 KB), warm 0,47 s (Hit, kein WFS) — identische Ergebnisse, WFS-Ausfall-resistent.