Major
Nice to have
Detail
Hintergrund
Konsistenzregeln können aktuell am Modell so gut wie überhaupt nicht ausgedrückt werden. Die einzige Form der Überprüfung sind "mandatory" Auszeichnungen und Unique-Keys direkt an den Tabellen in der Persistenzschicht.
Konsistenzregeln werden aktuell nur an der GUI hinterlegt und nur kurz vor dem Speichern überprüft.
Problem
Die Überprüfung an der GUI ist aus mindestens zwei Gründen problematisch:
- Die Überprüfung geschieht dezentral in Command-Handlern. Wenn das Modell erweiter wird, müssen u.U. viele Command-Handler angepasst werden.
- Die Überprüfung kurz vor dem Commit kann in einer Nebenläufigkeitssituation eine Inkonsistenz nicht verhindern, weil nicht sichergestellt werden kann, dass bis zum Commit nicht eine andere Änderung die Konsistenz des aktuell in Vorbereitung befindlichen Commits zerstört.
Ziel
Es bedarf einer deklarativen Möglichkeit, mit der man häufige Formen von Konsistenzreglen ausdrücken kann. Zusätzlich ist eine API notwendig, mit der man komplexe Tests im Kontext eines Commits durchführen kann.
Die Regeln sollen einerseits während in der Transaktion überprüft werden, aber sie sollen dem Nutzer auch schon während der Eingabe an der GUI Rückmeldungen geben können.
Anwendung
Ein Modell-Constraint kann entweder in-app als "Überprüfung" an einem Attribut oder einer Referenz definiert werden.
In Modell-XML kann das Constraint folgendermaßen deklariert werden:
#!xml <property name="myProperty" type="..."> <annotations> <constraints> <constraint-by-expression> <check> value -> self -> if($value and !$self.get(`DemoTypes:DemoTypes.A#booleanMandatory`), #('Darf nur gesetzt werden, wenn auch booleanMandatory gesetzt ist'@de, 'Must only be checked, if booleanMandatory is checked also.'@en)) </check> </constraint-by-expression> </constraints> </annotations> </property>
Ein Constraint-Check kann auch als Plug-In realisiert werden. Hierfür muss eine Implementierung von tl:ConstraintCheck erstellt werden und über <constraint class="..."/> zu der <constraints>-Annotation hinzugefügt werden. Vgl. tl:TLConstraints und tl:ConstraintCheck.
Code-Migration
- AttributeUpdateFactory.createAttributeUpdateFor...(...) muss den AttributeUpdateContainer zusätzlich übergeben bekommen.
- Gleiches gilt für MetaAttributeFilter.getSearchValuesAsUpdate(...).
- AttributeUpdateContainer.putAttributeUpdate(update) entfällt, weil ein Update bei der Konstruktion automatisch verknüpft wird.
- Gleiches gilt für AttributeUpdate.setDomain(...). Die Domain muss/kann bei der Konstruktion mit angegeben werden.
- Kleinere Signatur-Änderungen an StorageImplementation. setAttributeValue() -> internalSetAttributeValue(), Wrapper -> TLObject.
- Konfigurationsschema von GridCreateHandlerByExpression hat sich geändert.
- Ant-Task z_migrate_Ticket_10091 in eigenen Modulen ausführen.
- In-App-Layouts in der Datenbank werden automatisch beim nächsten Applikationsstart migriert.