Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auswertung AttributePath nicht korrekt #396

Open
Tracked by #418
edigonzales opened this issue Nov 16, 2023 · 5 comments
Open
Tracked by #418

Auswertung AttributePath nicht korrekt #396

edigonzales opened this issue Nov 16, 2023 · 5 comments

Comments

@edigonzales
Copy link
Contributor

CLASS Gemeinde =
   gueltige_Stimmen: 0..1000000;
END Gemeinde;

CLASS Kandidat =
END Kandidat;

  ASSOCIATION Gemeinde__Kandidatenstimmen =
     Gemeinde_R -- {1} Gemeinde;
     Kandidat_R -- {0..*} Kandidat;
     Stimmen: 0..1000000;
  END Gemeinde__Kandidatenstimmen;

CONSTRAINTS OF Gemeinde =
    MANDATORY CONSTRAINT Math.sum("\Kandidat_R->Stimmen") ==
gueltige_Stimmen;
  END;

-> Compiler meldet Fehler wegen Backslash: failed to scan file (unexpected char: 'K'). Escapen bringt auch nix.

Mit anderer Variante (expliziter Zwischenklasse) funktioniert es auch nicht:

CLASS Gemeinde =
  gueltige_Stimmen: 0..1000000;
END Gemeinde;

CLASS Kandidatenstimmen =
  Stimmen: 0..1000000;
END Kandidatenstimmen;

 ASSOCIATION Gemeinde__Kandidatenstimmen =
    Gemeinde_R -- {1} Gemeinde;
    Kandidatenstimmen_R -- {0..*} Kandidatenstimmen;
 END Gemeinde__Kandidatenstimmen;

CONSTRAINTS OF Gemeinde =
   MANDATORY CONSTRAINT Math.sum("Kandidatenstimmen_R->Stimmen") ==
gueltige_Stimmen;
 END;

-> Fehlermeldung: Error: incompatible values. Value
valueOfObjectPath=validator.getValueFromObjectPath() ist null. Umgekehrt funktioniert es, also CONSTRAINTS OF Kandidatenstimme etc. pp.

Archive.zip

@beistehen
Copy link

Hat wohl mit der Navigationsrichtung zu tun. Die Gemeindeobjekte haben ja keinen Hinweis darauf, welche Kandidaten(stimmen) auf sie verweisen. Die Objektreferenz auf das zugehörige Gemeindeobjekt ist bei den Kandidaten(stimmen) gespeichert.

@edigonzales
Copy link
Contributor Author

@beistehen Warum meinst du? Weil die Kardinalität der Rolle "Gemeinde_R" = 1 ist und es im Transfer "nur" beim Kandidat einen Verweis (aka REF) hat? Es funktioniert auch mit 1..* nicht, also wenn es im Transfer ein eigenes Assoziations-Element gibt, welche beide Klassen referenziert. Gibt es sowas in INTERLIS wie unidirektional und bidirektional bezüglich Assoziationen?

@beistehen
Copy link

Weil die Kardinalität der Rolle "Gemeinde_R" = 1 ist und es im Transfer "nur" beim Kandidat einen Verweis (aka REF) hat?

Ja.

Es funktioniert auch mit 1..* nicht, also wenn es im Transfer ein eigenes Assoziations-Element gibt, welche beide Klassen referenziert.

Gut zu wissen. Das habe ich noch nie ausprobiert.

Gibt es sowas in INTERLIS wie unidirektional und bidirektional bezüglich Assoziationen?

Meiner Erfahrung nach: ja. Aber ich lasse mich gerne eines Besseren belehren...

@edigonzales
Copy link
Contributor Author

Weil die Kardinalität der Rolle "Gemeinde_R" = 1 ist und es im Transfer "nur" beim Kandidat einen Verweis (aka REF) hat?

Ja.

Fände ich aber noch speziell, wenn das Navigieren davon abhängig ist, wie der Transfer aussieht. Du könntest ja auch für Kardinalität=1 ein separates Element machen im Transfer. Dito in der DB: Es gibt z.B. bei Hibernate auch bidirektionale OneToMany-Beziehungen. Da entsteht dann einfach eine Zwischentabelle in der DB.

@claeis
Copy link
Owner

claeis commented Nov 22, 2023

Das Transferformat ist nicht relevant.
Hingegen ob es zu 1 ist oder zu * ist relevant. Ueber eine zu * Rolle kann man mit der reinen ili-Sprache nicht navigieren (es fehlt das Konzept einer Wertemenge). Darum ist das formale Funktionsargument bei Math.sum() TEXT.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants