"functions" bei person

[nittka]

Es gibt drei Vorkommen des functions-Tags bei Personen (speedminster.xml Zeile 58-88). Im Code kann ich nicht finden, dass functions bei Personen ausgewertet wird. Kann es sein, dass mit den Werten 1 und 2 die Jobs gemeint sind, die für eine Person spezifiert werden können? Falls ja, würde ich hier functions durch job ersetzen.

[GWRon]

Ja...das sieht stark nach "jobs" aus.

[GWRon]

Wenn Sachen qualitativ zum allg. Datenbestand passen, koennen sie auch dorthin ueberfuehrt werden. Also die User DBs irgendwann in den allgemeinen Datenbestand integrierrn (ausser sie haben einen doch stark abweichenden Humor)

[nittka]

Übrigens kann job direkt als person-Property gesetzt werden oder im details-Knoten. Vom database-Einlesecode sieht es aber so aus, dass das zweite Einlesen aus den details ohne Fallback erfolgt (wenn als direktes Property definiert und dann details ohne job existiert, ist der Job wieder weg!?)

[GWRon]

Stimmt. Da sollte wohl ein Person.job hinten ran... Oder auch nicht.

Wenn bspweise eine zzz_spezial.xml angelegt wuerde und dort bestehende Personen ungeschrieben werden soellten... Dann wuerde ein "fallback" nur das Erweitern, aber nicht das Ersetzen ermoeglichen.

[GWRon]

Besser waere hier also ein has-check (nur einlesen, wenn Feld/property im XML vorhanden).

[nittka]

Willst Du ein nachträgliches Überschreiben wirklich unterstützen? (Das würde ja nicht nur Personen, sondern sämtliche Entitäten betreffen). Welchen Anwendungsfall hast Du denn für das "special.xml" im Hinterkopf? Mir fällt eigentlich nur Lokalisierung ein, aber da würde man ja auch keine Sachen überschreiben, sondern nur neue Sprachen ergänzen.

[GWRon]

Naja ..man koennte Balancing in einer Extradatei erlauben. Oder halt erweiternde Lokalisierung, neue Jobs, andere Geburtsdaten.

Die database-quellcode-Datei ist zumindest dafuer ausgelegt, nutzen wird es aber wohl (derzeit) keiner.

Es erlaubt jedenfalls die einfache Weitergabe der "diffs/Aenderungen".

[nittka]

Es klingt verlockend, scheint mir aber eher eine Büchse der Pandorra. Bei Lokalisierung gehe ich voll mit. Bei anderen Attibuten habe ich noch meine Zweifel; insb. weil es schwer werden kann Überschreiben und Ergänzen zu unterscheiden. Wenn man alle Attribute mitliefern muss, weil das Diff sonst die schon vorhanden mit "null"-Werten ersetzt ist das mit der einfachen Weitergabe von Diffs nämlich auch schon wieder nur halb richtig. Und umso wichtiger wäre, dass derselbe Wert nicht an mehreren verschiedenen Stellen definiert werden kann.

[nittka]

... Wahrscheinlich könnte es gutgehen, wenn man immer einen Bestandswert als Fallback verwendet. Wenn im überschreibenden Datensatz ein Eintrag vorhanden ist, überschreibt dieser den bestehenden Wert, ansonsten bleibt der alte bestehen. Das setzt natürlich voraus, dass es für alle Wertebereiche einen neutralen "Null-Wert gibt" (bei Flags 0, bei Jahreszahlen "-1", bei einfachen Strings kann es schwierig werden, da Blitzmax ja nicht zwischen null und Leerstring unterscheidet, oder?)

[GWRon]

Vieles wurde mit zu viel "Ambition" im Hinterkopf entworfen. Wir koennen gerne das Ganze hier verschlanken.

[GWRon]

genau ... du kannst nicht zwischen Null und Leerstring unterscheiden. Du kannst da nur "magic codes" nutzen (also "__EMPTYSTRING__" oder sowas einfuehren).

[nittka]

Bleibt erstmal noch offen, da der obige Fehler beim Einlesen des Jobs noch nicht mit behoben ist.

[nittka]

Überschreiben eines vorhandenen Jobs durch fehlende Definition in Details ist beim Datenbankaufräumen behoben worden (https://github.com/TVTower/TVTower/pull/346). Wenn man vorhandene Jobs explizit löschen möchte, sollte das durch funktion="0" möglich sein.