|
|
|
# Queries wit Roles
|
|
|
|
|
|
|
|
### Implemented Classes
|
|
|
|
- AQuery
|
|
|
|
- Query
|
|
|
|
- IQueryViewCompartment
|
|
|
|
- Query Helper
|
|
|
|
- Checking Option
|
|
|
|
|
|
|
|
## Anpassung der Code Generierung
|
|
|
|
- RSUM bekommt neue Klassen, welche das Erstellen von Schnittstellen und abstrakten Klassen ermöglichen im allegemeiner Queries zu definieren
|
|
|
|
- Diese Klassen erben von der Schnittstelle Query Helper und von der Klasse die sie repräsentieren
|
|
|
|
- Generierung eines neuen Query Views für jedes Ecore Model der von IQueryViewCompartment erbt
|
|
|
|
- Er erstellt eine verbundene Query und erzeugt Elemente darin, die nicht mit dem Rsum Verbunden sind
|
|
|
|
|
|
|
|
## Anpassung RSUM Packet
|
|
|
|
- AQuery ist eine abstrakte Repräsentation einer Query mit den Funktionen die sie implementieren muss
|
|
|
|
- AQueryObject in AQuery implementiert die boolean Variablen aus dem AMQL Paper
|
|
|
|
- Query ist eine direkte Implementierung, die das erzeugen für jede art von Query auf jedem RSUM erlaubt
|
|
|
|
- CheckingOption ist ein Enum für die Prüfung von Attribute Differenzen und ihrer Integration in die Ergebnisse
|
|
|
|
|
|
|
|
## Verbindung zum RSUM
|
|
|
|
- Element die im QueryView erstellt werden sind nicht im RSUM sondern nur nebenher existent
|
|
|
|
- Das erlaubt Queries nebenher laufen zu lassen und die nicht direkt mit RSUM zu verbinden
|
|
|
|
|
|
|
|
## Prozess
|
|
|
|
- neue Query anlegen (create QueryViewCompartment) (erledigt)
|
|
|
|
- Query neue Objekte geben (ie = new InternalElement; qc.addQueryRole(ie)) (erledigt)
|
|
|
|
- Query verändern (qo.returned = .. usw.) neue Werte setzen (erledigt)
|
|
|
|
- Query ausführen auf kompletter Datenbasis die im RSUM gespeichert ist (erledigt)
|
|
|
|
|
|
|
|
### Query Ergebnisse Visualisieren (erledigt)
|
|
|
|
|
|
|
|
#### Aus einer Query Sicht erstellen
|
|
|
|
- Alle Objecte die eine Rolle in der Query spielen müssen als Rollen im View Repräsentiert werden
|
|
|
|
- Query wird ausgeführt und die Ergebnisse werden dann in den View reingeladen
|
|
|
|
- View eigentlich nur lesbar, Ansonsten könnte man maximal noch Attribute von Elementen ändern lassen wenn die keine Attribute Abhängigkeit haben
|
|
|
|
- Query als JSON oder ModelJoin repräsentieren
|
|
|
|
- in Code Generator mit unterliegendem Model geben
|
|
|
|
- Neuen ViewType daraus erstellen
|
|
|
|
- Viewtype in RSUM laden und Query Ergebnis in view geben
|
|
|
|
|
|
|
|
#### Einfach Elemente in Reihe auflisten und ausgeben (erledigt) [reicht eigentlich zu da wir so die Elemente bekommen und modifizieren könnten wenn wir wollten]
|
|
|
|
- TODO: Modifizierung für Ergebnisse von Queries verbieten, schwer da es die originalen Objekte sind die ausgegeben werden, dafür vielleicht doch ein ReadOnly View nötig
|
|
|
|
|
|
|
|
#### Eine Query Ansicht haben, wobei jede Instanz davon eine neue Query repräsentiert und diese ausführen und modifizieren kann (erledigt)
|
|
|
|
|
|
|
|
## Erweiterung
|
|
|
|
- Query Ergebnisse in Editor anzeigen oder echt Elemente in einem View Highlighten |
|
|
\ No newline at end of file |
