efa Support Forum

Hallo,

in efa2 sind bestimmte Daten (z.B. Personen, Boote und Ziele) versioniert, d.h. zu ein und demselben Datensatz kann es mehrere Versionen mit unterschiedlichem Gültigkeitszeitraum geben. So kann zum Beispiel dieselbe Person zu verschiedenen Zeitpunkten einen unterschiedlichen Status haben (z.B. Junior-Mitglied bis 30.06.2011, Senior-Mitglied ab 01.07.2011), oder einen anderen Namen (z.B. durch Heirat). Selbst wenn es nur eine Version eines Datensatzes gibt, hat diese immer einen Gültigkeitsbeginn, ab dem der Datensatz gültig ist. Davor existiert er nicht. So kann man z.B. ein Boot, das erst nächste Woche getauft wird, schon heute in efa eintragen - mit Gültigkeitsbeginn der Bootstaufe.

Das Konzept der Versionierung ist sehr mächtig, aber auch etwas trickreich. Zwei von euch hatten beim Beta-Test das Problem, daß die eingetragenen Namen in manchen Fahrtenbucheinträgen spurlos verschwanden. Grund war, daß z.B. ein Boot, das erst ab dem 05.02.2012 gültig war, für eine Fahrt am 15.01.2012 eingetragen wurde - zu dem Zeitpunkt aber noch gar nicht existierte. efa hat den Eintrag zwar akzeptiert, hinterher aber den Bootsnamen nicht mehr angezeigt.

Das Thema ist ziemlich kompliziert, aber heute habe ich mal versucht, eine Lösung zu finden:

Die Auto-Vervollständige-Listen sind zur Zeit in efa noch statisch (jaja, steht auf dem Programm) und bieten zur Auswahl sämtliche Namen (Boote, Personen, Ziele) an, die in der Gültigkeit des Fahrtenbuchs irgendwann mal gültig sind. Wenn das Fahrtenbuch also von 1.1.2012 bis 31.12.2012 gilt, dann stehen da alle Namen drin, die in diesem Zeitraum zumindest teilweise gültig sind. Wenn nun für einen Fahrtenbucheintrag ein Name ausgewählt wird, der zum Zeitpunkt des Fahrtenbucheintrags nicht gültig ist, so erscheint dieser jetzt mit einem orangenen Button (bald brauche ich eine Legende für die Farben...).

Wenn der Eintrag hinzugefügt wird, und sich efa im Admin-Modus befindet, warnt efa und fragt den Admin, ob der Eintrag mit dem Namen (der zur Zeit nicht gültig ist) hinzugefügt werden soll. Wenn der Admin ja wählt, wird der Eintrag hinzugefügt, und der Name als unbekannter Name behandelt. Er hat damit zwar die gleiche Schreibweise wie der Datensatz, der zu einem anderen Zeitpunkt mal gültig ist, ist jedoch für efa davon völlig unabhängig und würde bei der Statistikauswertung auch nicht mit diesem Datensatz zusammengefaßt werden.

Im Bootshaus-Modus, wo ein Mitglied mit dieser Frage wohl etwas überfordert wäre, wird lediglich eine Warnung im Logfile protokolliert (Warnungen werden alle 7 Tage zusammengefaßt dem Admin zugestellt), und der Eintrag ebenfalls mit einem unbekannten Namen gespeichert, wie oben.

Es sollte jetzt also für den Admin ersichtlich sein, was passiert. Er kann dann, je nachdem, die Gültigkeit des Datensatzes anpassen, oder es dabei belassen.

Ein unbekannter Name in einem Fahrtenbucheintrag wird jedoch zur Zeit nur durch Änderung der Gültigkeit eines gleichnamigen Datensatzes nicht plötzlich zu einem bekannten Namen, wenn der Fahrtenbucheintrag jetzt in die Gültigkeit des Datensatzes fällt. Das passiert erst, wenn auch der Fahrtenbucheintrag vom Admin noch einmal bearbeitet wird. Auch das steht schon auf meiner Todo-Liste, daß efa in dem Audit, der bei jedem Öffnen des Projektes alle Daten überprüft, auch Einträge im Fahrtenbuch korrigiert (insb. was Versionierung betrifft). Kommt noch....

Wenn (von Hand) ein neuer Datensatz angelegt wird, dann schlägt efa einen Gültigkeitsbeginn für diesen Datensatz vor. Bislang war das 00:00:00 am Tag der Erstellung. Es gab den Wunsch, daß standardmäßig ein neu angelegter Datensatz ab immer gültig ist (technisch ab 1.1.1970). Das habe ich jedoch so nicht umgesetzt -- es könnte ja zum Beispiel sein, daß vor vielen Jahren mal ein gleichnamiges Boot existiert hat, das inzwischen verschrottet wurde, und nun ein neues Boot (mit gleichem Namen) eingetragen wird. Damit würde es also zu bestimmten Zeiten zwei gleichnamige Boote geben. efa erlaubt dies sogar (das ist kein Fehler), warnt aber beim Anlegen eines solchen zweiten (gleichnamigen) Datensatzes davor. Auch insgesamt halte ich es nicht für klug, wenn ich heute ein neues Mitglied eintrage, daß das auch für alle Vergangenheit sichtbar ist. Statt dessen habe ich mich entschieden, als vorgeschlagenen Gültigkeitsbeginn den Gültigkeitsbeginn des derzeit geöffneten Fahrtenbuchs zu wählen (üblicherweise 01.01. des Jahres). Das erscheint mir eine ganz vernünftige Lösung. Damit ist der Datensatz nicht ewig in die Vergangenheit gültig. Andererseits kann ich heute einen neuen Datensatz anlegen und anschließend für letzte Woche eine Fahrt damit eintragen, ohne daß ich beim Anlegen des Datensatzes aufpassen muß, welches Datum ich wähle. Natürlich kann das vorgeschlagene Datum immer angepaßt werden.

Ist so in 1.9.9_35 realisiert.

Rückmeldungen sind willkommen!

Danke & Gruß,
Nicolas

Hallo,

Mit der Lösung könnte man glaub ich leben. Ich halte die Versionierung insgesamt für "sehr anspruchsvoll"...

Hallo Lars,

die Versionierung ist sicherlich etwas anspruchsvoll - aber so ist auch das wahre Leben, das efa abbilden muss. Irgendwie muessen diese Probleme, dass sich fuer eine Person z.B. der Name oder Status aendern, ja geloest werden. Das sind ziemlich alltaegliche Probleme. In efa1 gab es dazu z.B. Synonyme - man konnte definieren, dass zwei Namen A und B eigentlich derselbe sind. Ist das einfacher? Auf jeden Fall ist es sehr haesslich, mindestens ebenso fehleranfaellig, und weniger maechtig. Ich gebe zu, dass man das mit der Versionierung erstmal verstehen muss. Aber eigentlich ist das Konzept recht logisch, und auch auf eine gewisse Weise deutlich natuerlicher als etwa die Synonyme in efa1. Und fuer viele Datensaetze wird es auch in efa2 bei nur einer Version bleiben.

Und wie gesagt: Fuer geniale Vorschlaege, wie das Konzept noch vereinfacht oder verbessert werden koennte, bin ich natuelich dankbar!

Gruss,
Nicolas

Hi,

ich habe einen genialen Vorschlag:

Eine Funktion, die bei allen Einträgen (für die, die das wollen wie z.B. wir das Datum auf einen Rutsch auf einen eingebbaren Wert setzt. Ich muss nämlich sonst jedes Boot, jede Strecke und vor allem jeden Ruderer von Hand anfassen... EDV zu Fuß.

Quasi als Gedankengang: "update boote set start="1.1.1970" where 1" aber ich hab (leider) die Version mit File-DB installiert... Ich traute der Beta in Bezug auf SQL-DB leider nicht.

Die Versionierung ist toll, aber sowas haben nicht mal ausgewachsene Krankenhausinformationssysteme, warum eine Bootsverwaltung das dann unbedingt brauchen soll, wage ich zu bezweifeln. Aber wenn es Dir wichtig ist... der Programmierer ist der Chef Andere können es ja anders machen, wenn sie meinen... Ist halt Dein Ding.

Wenn eine/r Heiratet, kann man den Namen auch einfach ändern... In alten Statistiken muss da nicht unbedingt der alte Name auftauchen.
Ein Boot mit dem Flag "ausser Betrieb", "nicht mehr im Bestand" oder sonstwas zu versehen, macht auch Sinn. Braucht auch keine Versionierung.
Und grundsätzlich brauche ich für eine Gültigkeit "ab" und "bis" auch keine Versionierung.

Es ist halt programmiertechnisch alles andere als trivial, das sauber umzusetzen. Ich (in meiner persönlichen, nicht bös zu sehenden Meinung) finde, dass Du in der Zeit besser andere, wichtigere Dinge für efa2 machen könntest )))))))))))))))))))))))))

Oder hast Du ein relevantes Killerargument für Versionierung?

Das ist wie mit einigen Models. Schön, aber Sinnlos. Mehr Selbstzweck als Nutzen (IMHO)

Aber dass soll nicht davon ablenken: efa(2) ist ein tolles Programm! Danke, danke vor allem für GPL!!!

Hallo Lars,

lua hat geschrieben:ich habe einen genialen Vorschlag:

Eine Funktion, die bei allen Einträgen (für die, die das wollen wie z.B. wir das Datum auf einen Rutsch auf einen eingebbaren Wert setzt. Ich muss nämlich sonst jedes Boot, jede Strecke und vor allem jeden Ruderer von Hand anfassen... EDV zu Fuß.

Unter Linux/UNIX:
Das ist zwar nicht die aller benutzerfreundlichste Lösung, aber sie funktioniert! Ein Texteditor, der Suchen&Ersetzen mit regulären Ausdrücken beherrscht, tut's auch. Eine andere Lösung habe ich leider zur Zeit nicht.

lua hat geschrieben:Quasi als Gedankengang: "update boote set start="1.1.1970" where 1" aber ich hab (leider) die Version mit File-DB installiert... Ich traute der Beta in Bezug auf SQL-DB leider nicht.

Du hast die SQL-DB-Funktion noch gar nicht ausprobiert? Da gibt's noch nicht viel zum nicht trauen: Wenn Du versuchst ein Projekt mit dieser Option zu erstellen, bekommst Du eine Fehlermeldung, daß diese Funktion noch nicht unterstützt wird...

lua hat geschrieben:Wenn eine/r Heiratet, kann man den Namen auch einfach ändern... In alten Statistiken muss da nicht unbedingt der alte Name auftauchen.
Ein Boot mit dem Flag "ausser Betrieb", "nicht mehr im Bestand" oder sonstwas zu versehen, macht auch Sinn. Braucht auch keine Versionierung.
Und grundsätzlich brauche ich für eine Gültigkeit "ab" und "bis" auch keine Versionierung.

Ja, da ist was dran. Aber es gibt auch Situationen, die Du damit nicht richtig abbilden kannst. Dein ursprüngliches Problem mit der Gültigkeit der Datensätze hat so betrachtet dann auch gar nichts mit der Versionierung zu tun, sondern nur mit der Gültigkeit (denn Du hattest ja nur eine Version, und somit gar keinen Gebrauch von der Versionierung gemacht). Das ist nebenbei bemerkt auch eine interessante SIchtweise, fällt mir gerade auf. efa2 zwingt dich nicht dazu, von der Versionierung Gebrauch zu machen. Du kannst alle Änderungen an einem Datensatz auch machen, ohne eine neue Version zu erstellen. Nur wenn Du es willst (und explizit anklickst) wird eine neue Version erstellt.

lua hat geschrieben:Es ist halt programmiertechnisch alles andere als trivial, das sauber umzusetzen. Ich (in meiner persönlichen, nicht bös zu sehenden Meinung) finde, dass Du in der Zeit besser andere, wichtigere Dinge für efa2 machen könntest )))))))))))))))))))))))))

Zum Beispiel eine Touchscreen-Oberfläche?
Ja und nein, aus meiner Sicht war das wichtig.

lua hat geschrieben:Oder hast Du ein relevantes Killerargument für Versionierung?

Das eine Killerargument nicht, aber viele kleine Argumente. Immerhin entwickle ich efa seit fast 11 Jahren. Angefangen hat efa als kleines Tool für mich selbst, ohne daß ich mir viel Gedanken über das Design gemacht hätte. Über die Zeit ist es dann gewachsen (und gewuchert). Das Ziel von efa2 war ein technischer Neuanfang - Dinge von Grund auf besser zu machen, die in efa1 einfach nicht gut gelöst waren und immer wieder zu Problemen geführt haben.

Die Versionierung von efa1 war ein Graus: efa1 hat zu jedem Fahrtenbuch eigene Mitglieder-, Boots-, und Ziellisten gepflegt. Beim Anlegen eines neuen Fahrtenbuchs wurden diese als Kopie des vorherigen Fahrtenbuchs erzeugt. Das ist ok, um Änderungen nicht rückwirkend geltend zu machen. Aber doof, wenn man doch etwas rückwirkend ändern will, weil es immer schon falsch erfaßt war.

In efa1 gibt es eine ganze Reihe von Situationen, die sich dort nicht gut lösen lassen, und mit Versionierung deutlich eleganter, und (wenn man das Konzept verstanden hat) auch einfacher machen lassen:

• Die Person, die heiratet (ja, man könnte sie könnte ihren alten Namen auch softwaretechnisch ganz ablegen)
• Der Gast, der zur Mitte des Jahres zum Mitglied wird. Wenn ein Verein auswertet, wieviele Kilometer im Jahr von Gästen gerudert werden, sollten die Kilometer der ersten Jahreshälfte dieser Person als Gast, nicht als Mitglied gewertet werden. Falls er an DRV-Fahrten teilgenommen hat, dürfen diese (solange er noch Gast war) gar nicht berücksichtigt werden.
• Das Boot, das nächste Woche getauft wird, das ich aber heute schon eintragen möchte, weil ich nächste Woche im Urlaub bin.
• Gruppen, deren Mitglieder sich im laufe des Jahres ändern, und die dafür benutzt werden, zu definieren, wer mit welchem Boot fahren darf. Wenn ich am Ende des Jahres auswerten möchte, wer unerlaubt ein Boot benutzt hat, muß ich zu jedem Zeitpunkt wissen, wer zum Zeitpunkt einer Fahrt der Gruppe angehörte und wer nicht.
• Mein Vorstand beschwert sich immer wieder, daß ich im erkläre, ich kann Mitglieder, die zur Mitte des Jahres austreten, erst zum Ende des Jahres aus efa1 löschen. Bis dahin erscheinen sie immer noch schön in den Auto-Vervollständige-Listen.

Und als letzes Argument vielleicht das, was Du mir gewissermaßen vorwürfst (im nett gemeinten Sinn): Ja, es ist wahr. Es macht Spaß, so etwas zu implementieren. Es gibt vieles, was beim Programmieren einfach nervig ist, vor allem das Umgehen mit zahlreichen Fehlersituationen durch Fehleingaben usw. Viel Fummelarbeit. Aber die Basistechniken, wie das Hantieren mit den Daten, das macht Spaß. Zumindest mir. Ich habe mit efa2 nicht nur Versionierung implementiert, sondern eine ganze File-basierte Datenbank. Es gibt einen asynchronen DB-Writer im Hintergrund, synchron geschriebene Redologs, im Falle eines Crashes eine automatische Crash-Recovery aus den Sicherungskopien und dem Redolog. Auf Anregung von Andreas gibt es jetzt auch ein host-based Mirroring. Es gibt Locking auf Datensatz- und Tabellenebene, und natürlich eine Deadlock Detection (na gut, nennen wir es mal bescheiden einen TImeout ). Optimisitc Locking zur Erkennung von Update-Konflikten. Beliebig viele Indices pro Tabelle für Lookups, die nicht auf Primary Keys basieren. Virtual Columns. Unique und Foreign Key Constraints. Backup & Restore. Und, braucht man das alles? Gewissermaßen schon, wenn man ein Programm sicher und ohne Datenverlust betreiben will. Muß man das alles selbst entwickeln? Naja, SQLIte hat mir nun überhaupt nicht gefallen, und ich wollte auf jeden Fall eine file-basierte Speichertechnik anbieten, weil ich nicht allen meinen Nutzern zumuten will, nicht nur efa-Admin, sondern auch DBA zu sein. 90% der Admins in den Vereinen wären damit überfordert, eine eigene Datenbank aufzusetzen und zu betreiben. Und wieviel Aufwand war das ganze? Tja, schwer zu sagen. Ein Großteil der Klassen, die hier zum Einsatz kommen, werden auch im Remote-Zugriff verwendet, einem weiteren Highlight, wie ich finde. Den braucht man nun wirklich (zumindest bin ich man). Und durch diese recht generischen Konzepte, wird plötzlich alles sehr einfach und elegant. Es hat mich zwar viel Zeit gekostet, die ganze Basistechnik zu bauen, aber jetzt, wo sie da ist, ist das Entwickeln neuer Funktionalität viel einfacher geworden als in efa1, wo es zum Ende hin nur noch mühsam war, irgendwo ein neues Feature ranzuflanschen.

Reicht das als Begründung?

Gruß,
Nicolas

PS: Du wirst lachen, aber eine SQL-Schnittstelle für efa habe ich auch schon vermißt. Eventuell werde ich die noch ins CLI einbauen. Fully SQL-92 compliant wird sie wohl nicht. Aber ich brauche fürs CLI ohnehin eine Möglichkeit, einen Datensatz zu updaten. Also auch zu suchen. Warum also nicht an der SQL-Syntax orientieren. So kompliziert ist die ja nicht. Ich werde sicher keine Joins unterstützen, aber die absoluten Basics vielleicht schon. Aber das liegt noch etwas in der Zukunft, und ich werde es auch kaum als SQL anpreisen, sondern lediglich als ein CLI, das zufälligerweise sich etwas an der SQL-Syntax orientiert (und die wirst selbst für ein simples SELECT Statement vermutlich nur ähnlich und nicht identisch sein).

Na da hab ich ja einen Punkt getroffen, was?

Es freut mich, dass es anderen auch so geht wie mir. Wie soll ich meiner Frau erklären, das wochenlange Arbeit in einem mit forth-programmierten Mikrocontroller steckt, damit ich vom Wohnzimmer aus das Garagentor mit einem shell-Befehl öffnen kann, den Zisternenstand sehe oder ähnliches. Überhaupt, wie soll man irgendwem erklären, forth zu programmieren. Na ja, neben C, Assembler, Python, PHP, Basic, Java und was man sonst noch alles mit sich rumschleppt: eben weil es Spaß macht!

Insofern freut es mich einfach unglaublich, dass Du an einer Sache Spaß hast, die mir (und so vielen anderen) auch noch so viel nützt

Von mir aus auch mit versionierten Datensätzen Ist schon edel, keine Frage.

Und ja, eine Touch-Oberfläche hab ich immer noch im Kopf, angedockt per SQL an efa. Auf die CLI freu ich mich schon jetzt!

Und zu deiner eigenentwickelten File-Datenbank: Respekt! Da hast Du richtig Arbeit und Idee reingesteckt. Ich wäre wohl so faul und hätte nur eine Anbindung an MySQL verwendet.

So, und jetzt werd ich mir die Gültigkeit in die Files reinhacken, danke für die Info! War schon auf dem Weg mit vi die Dateien mal anzuschauen

Hallo Lars,

das CLI gibt es schon heute, nur die SQL-like Abfragen noch nicht.

Zum Thema Touchscreen habe ich mal einen separaten Thread erstellt.

Zu meiner Datenbank will ich nur noch kurz nachschieben, daß es sich im eigentlichen Sinne nur begrenzt um eine Datenbank handelt, und ich in meinem letzten Posting mit einem Zwinkern recht frei mit vielen Schlagworten gespielt habe. In efa sind diese Konzepte zwar alle irgendwie umgesetzt, aber können sich kaum mit einer voll ausgewachsenen Datenbank messen. Dieses Statement bin ich wohl auch meinem Arbeitgeber schuldig. Für den Zweck von efa reicht das aber völlig. Das nur als kleinen Disclaimer, falls hier jemand langkommt und sich fragt, wie ich mir hier hochtrabend anmaße, efa's XML-Dateien als Datenbank zu bezeichnen.

Gruß,
Nicolas

Das Konvertieren in den xml-files hat super funktioniert. Offensichtlich hat er den Verweis auf den "Quasidatensatz" (ohne Datenbank auch kein Datensatz korrekt gespeichert; der war dann nur entsprechend noch nicht gültig!

Ich habe also nicht mal was nacherfassen müssen, puh!

Achso, ja - die Referenzen waren da. Das war ja das besonders unschoene (oder in Deiner Situation: glueckliche) an der Sache - GUI und Datensaetze out of sync. Unschoen... aber ist ja jetzt zum Glueck gefixed, und Dein Problem ist auch geloest.

Nick