Abbildung von nicht beendeten/offenen Verträgen: `vertragsende` und `vertragsteilende` nullable machen

[hf-kklein]

Die fachliche Anforderung

Ich möchte offene/nicht beendete Verträge in BO4E abbilden.
Ich muss aber sowohl bei bo.Vertrag als auch bei com.vertragsteil zwingend ein vertragsende DateTime[1] bzw. vertragsteilende Date[1] angeben.

Gibt es schon eine Idee zur Umsetzung?

• bo.Vertrag.vertragsende nullable machen (neu DateTime[0..1] statt bisher DateTime[1])
• com.Vertragsteil.vertragsteilende nullable machen (neu Date[0..1] statt bisher Date[1])

Weitere Anmerkungen / Vorhandener Workaround

Der bisherige Workaround ist: Nimm sowas wie 9999-12-31 oder 9999-12-31T23:59:59 oder 9999-12-31T23:59:59.9999. Das Problem an diesem Workaround ist, dass das größtmögliche Datum von System zu System variieren kann: Das maxdate(time) in Java sieht anders aus als das maxdate(time) in Python sieht anders aus als das maxdate(time) in verschiedenen SQL-Datenbanken und das maxdatetime in deutscher Lokalzeit ist anders als das maxdatetime in UTC (je nachdem wie der timestamp intern abgebildet wird).

Bei der Zusammenarbeit mehrerer Systeme kann das zu unnötigen Problemen führen.

[hf-kklein]

@snsttr @PMSchroer ist mein Vorschlag für euch ein gangbarer Weg?

[PMSchroer]

Hierzu müßte das BO verändert werden. D.h. es muss eine neue Version des BOs geben. Finde ich ehrlichgesagt nicht so gut. Für Programmierer erschwert es die Sache ebenfalls. Es muss dann immer zusätzlich geprüft werden, ob ein Nullwert vorliegt. Daher würde ich ein einheitliches Datum weit in der Zukunft vorziehen. Soweit ich weis, nimmt ene't immer den 31.12.2999.

[hf-kklein]

es muss eine neue Version des BOs geben

Wenn wir den Standard verbessern wollen, müssen wir auch bereit sein, Bestehendes zu ändern; So wie es bisher auch schon gemacht wurde. Jede Änderung (auch an Enums, COMs usw) sorgt indirekt für andere Versionionen der BOs.

Die Frage sollte daher nicht sein: "Ist eine neue Version nötig?" sondern: "Würde der Standard besser, wenn wir es ändern?" Wie viele Änderungen wir dann in einezlnen Versionen (Major, Minor, Patch) zusammenfassen ist von der Frage, ob wir es ändern unabhängig.

31.12.2999

wirklich 2999? Das fände ich unintuitiv.

[snsttr]

Ich persönlich finde die nullable-Lösung sauberer.

Der Grund für die "2999-12-31" Lösung bei uns intern ist dem Usecase geschuldet: Beim Ausdruck von Gültigkeiten auf Datenbank-Ebene lassen sich Queries einfacher gestalten, wenn nicht immer explizit auf null geprüft werden muss. Im BO-Kontext sehe ich das aber etwas anders. Vor allem auch in Bezug auf deine Beschreibung der potentiellen Probleme, @hf-kklein.

Wenn wir die Vorgehensweise ändern, sollten wir aber alle DateTime-Felder prüfen bzw. allgemein beschreiben, dass in diesem Kontext null als unendlich/unbestimmt gilt.

Ich bin auch der Meinung, dass eine neue BO / API Version kein Hindernis sein darf. Die Verbesserung des Standards erfordert hin und wieder Breaking Changes.

[PMSchroer]

Peter weist auf zwei Probleme hin: 1.)Wie unterscheiden wir zwischen "es erfolgte gar keine Eingabe eines Wertes" und dem bewussten setzen des Wertes auf Null. 2.)Gilt Ähnliches nicht auch für Zahlenfelder(z. B. Max. Integer). Soll hier auch bewusst "Null" zugelassen werden? Ich weise auch darauf hin, dass wir endlich eine Vorgehensweise für die Versionierung verabschieden sollten. Versionieren wir den Gesamtstandard oder jedes BO? Wie oft können wir neue Versionen herausbringen? Woher weiß man, elche Version der Komponenten und der Enums zu welcher BO-Version gehört? PM Von meinem Telefon gesendet

…

-------- Ursprüngliche Nachricht -------- Von: Tim Steufmehl ***@***.***> Datum: Fr., 2. Dez. 2022, 16:39 An: bo4e/BO4E-python ***@***.***> Cc: Peter Martin Schroer | ene't ***@***.***>, State change ***@***.***> Betreff: Re: [bo4e/BO4E-python] Abbildung von nicht beendeten/offenen Verträgen: `vertragsende` und `vertragsteilende` nullable machen (Issue #434) Ich persönlich finde die nullable-Lösung sauberer. Der Grund für die "2999-12-31" Lösung bei uns intern ist dem Usecase geschuldet: Beim Ausdruck von Gültigkeiten auf Datenbank-Ebene lassen sich Queries einfacher gestalten, wenn nicht immer explizit auf null geprüft werden muss. Im BO-Kontext sehe ich das aber etwas anders. Vor allem auch in Bezug auf deine Beschreibung der potentiellen Probleme, @hf-kklein<https://github.com/hf-kklein>. Wenn wir die Vorgehensweise ändern, sollten wir aber alle DateTime-Felder prüfen bzw. allgemein beschreiben, dass in diesem Kontext null als unendlich/unbestimmt gilt. Ich bin auch der Meinung, dass eine neue BO / API Version kein Hindernis sein darf. Die Verbesserung des Standards erfordert hin und wieder Breaking Changes. — Reply to this email directly, view it on GitHub<#434 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXVIDQUQFIGFIEEUDCGTB6TWLIJ4RANCNFSM6AAAAAASQUMTE4>. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[hf-kklein]

Die nullable-lösung würde gut mit #465 zusammenpassen.

[hf-kklein]

Jetzt wo alles nullable ist wäre der Vorschlag direkt möglich/einsetzbar. Ich hätte gerne noch einen Satz in der Doku dass wir ausdrücklich nicht den 31.12 irgendeines Jahres in ferner Zukunft verwenden um offene Verträge zu modellieren.

[lord-haffi]

Frage aus dem BO4E-Gremium: Gibt es "offene" Verträge so überhaupt noch? Oder sind das mittlerweile nicht eher alles Verträge mit explizitem Vertragsende, die jedoch automatisch verlängert werden?
Relevanter PR zum Rework der Vertrages: #1087