rowe42 / lhm_animad_admin_html5

0 stars 6 forks source link

Backend Datenbank-Constraints werden im Frontend nicht verständlich interpretiert #218

Closed rowe42 closed 6 years ago

rowe42 commented 6 years ago

Beispiel: Ein Gehege anlegen und dabei ein Tier verwenden, das bereits einem anderen Gehege zugeordnet ist. Im Backend wird eine Datenbank-Bedingung verletzt. Im Frontend wird ein Fehlercode 409 ausgegeben, ohne weitere Erklärung. Erst nach Analyse des Backend-Logs versteht man, warum das nicht ging.

Erwartet: Eine Fehlermeldung, die den Sachverhalt verständlich erkärt.

@xdoo @dragonfly28 @ejcsid @Baumfrosch

DirkGern commented 6 years ago

Setzen wir DB-Constraints ein also RI-Checks im DBMS? In meiner Jugend war das verboten. Wer soll das noch verstehen? Was passiert beim Wechsel der DB?

Dr-Thomas-Tensi commented 6 years ago

Ich bin nicht @Baumfrosch s Meinung: RI-Checks im DBMS sind auf jeden Fall eine sinnvolle Dokumentation. Und bei einem DB-Wechsel werden sie halt in der Ziel-DB nachgebaut. Wer sagt denn, dass nicht irgendein Hugo direkt auf die Datenbank zugreift... Warum wird denn überhaupt die Integritätsbedingung der DB verletzt? Der Anwendungskern muss doch sicherstellen, dass die Regeln eingehalten werden, oder?

DirkGern commented 6 years ago

OK, ich habe mich unglücklich ausgedrückt. Verboten ist es , sich auf RI-Checks in der DB zu verlassen. Die Checks werden auf jeden Fall im Anwendungskern geprüft.

xdoo commented 6 years ago

Wir machen aktiv gar nichts im DBMS. Das passiert alles implizit über JPA. Die Doku findet ihr hier: https://en.wikibooks.org/wiki/Java_Persistence/OneToMany

@rowe42 Ich glaube nicht, dass man es schafft eine Fehlermeldung zu erzeugen, die den Sachverhalt erklärt. Zumindest nicht automatisiert. Dazu bräuchte man fachliches Wissen, was in dieser Situation erlaubt ist und was nicht. Das haben (und wollen wir auch) nicht im Modell.

Man kann das aus meiner Sicht aber über fachliche Geschmacksrichtungen lösen:

  1. Man kann nur Objekte auswählen, die noch keinem anderen Objekt zugeordnet wurden. D.h. es werden nur Tiere angezeigt, die in noch keinem Gehege vorhanden sind.
  2. Man kann Objekte umhängen. D.h. es werden nur Tiere angezeigt, die bereits einem Gehege zugeordnet sind und diese kann man dann von einem Gehege in das andere überführen. Beispielsweise das Kaninchen vom Streichelzoo ins Schlangenhaus.

Im ersten Schritt würde ich aber unsere aktuelle Lösung so belassen und den Fehlercode 409 mehr oder weniger generisch interpretieren. Wenn man die Meldung ausgibt, dass beim Speichern ein Konflikt aufgetreten ist, dann ist das für den Nutzer ja schon mal ein Hinweis.

ejcsid commented 6 years ago

Beschluss aus der RefArch: Für Milestone 2 sollen die 4*-Nummern in locales.json Fehlertexte bekommen.

Die Vorschläge von @xdoo kommen in ein eigenes Ticket für Milestone 3.

rowe42 commented 6 years ago

4*-Nummern haben nun eigene Fehlertexte im locales.json. Schließe das Issue.