Was ihr nicht alles mit der Plattform macht :)
Da wir im Standard hierzu aktuell keine Funktionen anbieten, müssten wir für eine solche Anforderung andere Wege gehen.
Hierbei haben wir 2 Themen:
- Wie kriegen wir die Daten
- Wie können wir ereignisbasiert auf Änderungen reagieren, um diese Daten wegzuschreiben
Thema 1: Daten holen
Hierfür müssen wir das r3 Anwendungsschema auslesen.
Der saubere Weg wäre, dass wir eine öffentliche API anbieten, wo wir Schemadaten bereitstellen und/oder auch aktualisieren können. Dann wäre das Upgrade-Safe und wir könnten irrelevante, interne Strukturen abstrahieren. Das wäre aber ein Projekt und dafür müssten wir Finanzierung sicherstellen.
Aktuell ist der "einfachste" Weg, direkt das Anwendungs-Schema aus der DB auszulesen. Um deine angefragten Daten auszulesen, hättest du folgendes SQL:
SELECT a.id AS attribute_id, a.name AS attribute_name, r.name AS relation_name
FROM app.attribute AS a
JOIN app.relation AS r ON r.id = a.relation_id
WHERE a.content = 'files'
AND r.module_id = 'ABC'
ABC wäre hier die Anwendungs-ID aus dem Builder. Wenn du die Zeile weglässt, kriegst du die Infos über alle Anwendungen.
Ich bin nie ein Freund, direkt im Anwendungs-Schema rumzustochern - wenigstens hat sich in diesem Bereich seit r3 1.0 strukturell nix geändert. Zudem lesen wir nur, machen also sonst nichts kaputt.
Thema 2: Ereignisbasiert reagieren
Da das Anwendungs-Schema in r3 keine Trigger anbietet, müsstest du selbst eine Trigger-Funktion in Postgres hinterlegen. Das ist keine Magie und du kannst dir die Definition fast 1:1 aus einer regulären Trigger-Funktion aus r3 abschauen.
Du brauchst ansonsten nur einen Namen und ein Ort, wo die Trigger-Funktion lebt. Ich würde dafür wahrscheinlich ein eigenes DB-Schema in der gleichen DB anlegen. Mit den richtigen Berechtigungen, kannst du dann einen Trigger auf die Relation app.attribute setzen, um dann bei Änderung eine Relation in eine deiner r3-Apps mit den Details zu befüllen.
Wenigstens hier kommt uns r3 entgegen, weil auch schreibende SQL-Zugriffe auf r3-Relationen sauber unterstützt werden.
Mit der Lösung lebt alles in Postgres, hat immer entsprechenden Zugriff und du brauchst dir über Skripte oder Timings keinen Kopf zu machen.
