Unnötige DB Attribute löschen

[JohannMaierhofer]

Da wir mit der 3.0.0 nicht mehr auf eine ältere Version zurück können, kann man nicht mehr benutzte Attribute löschen.

Gibt es noch weitere?

Wegen der Migration kann man das erst nach #600 übernehmen.

[JohannMaierhofer]

Man könnte natürlich jetzt die Chance nutzen und die DB Tabelle Mitgliedskonto in Sollbuchung umbenennen evtl. auch noch die Spalten "Mitgliedskonto" in anderen Tabellen die auf die Sollbuchung verweisen.
Dann müsste man aber auch den Code durchgehen und schauen wo mitglieskonto in SQL Strings verwendet wurde.
Das gleiche könnte man auch mit Adresstyp machen den wir ja jetzt Mitgliedstyp nennen.

Es wäre halt jetzt eine Möglichkeit das gerade zu biegen. Die Frage ist ob sich das lohnt. Es würde halt zukünftigen Entwicklern das Leben leichter machen.

[JohannMaierhofer]

Es stellt sich sowieso die Frage, ob man die in #480 angedachte Umbenennung von Mitgliedskonto in Sollbuchung und Adresstyp in Mitgliedstyp überhaupt ohne eine Umbenennung in der DB machen sollte.
Ich glaube das könnte noch mehr Verwirrung auslösen.
Man würde z.B. ein DBIterator it = service.createList(Sollbuchung.class); machen aber wenn man dann einen Filter hinzufügt, wo der Klassenname nötig ist, dann würde man "mitgliedskonto.betrag" schreiben. Das verwirrt ja noch mehr.

Ich glaube also fast, dass wir entweder Mitgliedskonto und Adtresstyp überhaupt nicht umbenennen oder eben zusammen mit einer Umbenennung in der DB.

PS: Es gibt übrigens schon so einen Fall bei dem ich erst verwirrt war. Im Code heißt es Zusatzbetrag, die dazugehörige DB Tabelle heißt aber zusatzabbuchung.

[lenilsas]

Ich fände es gut die Umbenennungen zu machen. Das bedeutet aber schon einiges an Arbeit, da auch die Variablen umbenannt werden sollten.
Wenn wir jetzt die DB überarbeiten wäre es auch gut die Eistellungen Tabell wie besprochen zu verändern. Dabei habe ich mich gefragt, ob wir das vorgeben der DB Updates verändern sollten. Momentan werden bei einer Neuinstalation alle Updates durchlaufen. Wäre es nicht besser eine create datei zu erstellen die auf einmal alles erstellt ohne Spalten hinzuzufügen, umzubenennen und zu löschen. Das wäre weniger fehleranfällig. Allerdings müsste man dan das crester und das Update getrennt pflegen.

[JohannMaierhofer]

Ich habe ja mal den #347 erstellt wegen der Probleme mit der derzeitigen Version von H2DB. Das könnte man ja mal für eine 4.0.0 vorsehen. Da hier keine Migration möglich ist wäre das dann evtl. auch ein Zeitpunkt wo man eine Create Datei erstellen könnte und dann alle alten Upgrade Dateien wegwirft.
Wie man dahin Migriert ist sowieso die Frage.

[JohannMaierhofer]

Ich fände es gut die Umbenennungen zu machen. Das bedeutet aber schon einiges an Arbeit, da auch die Variablen umbenannt werden sollten. Wenn wir jetzt die DB überarbeiten wäre es auch gut die Eistellungen Tabell wie besprochen zu verändern. Dabei habe ich mich gefragt, ob wir das vorgeben der DB Updates verändern sollten. Momentan werden bei einer Neuinstalation alle Updates durchlaufen. Wäre es nicht besser eine create datei zu erstellen die auf einmal alles erstellt ohne Spalten hinzuzufügen, umzubenennen und zu löschen. Das wäre weniger fehleranfällig. Allerdings müsste man dan das crester und das Update getrennt pflegen.

Du hast Recht, da müsste man auch die Variablen ändern. Da wir wegen der behobenen Fehler möglichst schnell eine neue Version rausgeben sollten, denke ich, ist das nichts mehr für die 3.0.0 ist. So kurzfristig sollten wir so umfangreiche Dinge nicht mehr machen.

Das würde ich mir dann lieber für eine 4.0.0 aufheben. Da könnte man dann auch auf den Umstieg zu einer neuen H2DB Version nachdenken. Hier kommt mir gerade ein möglicher Weg.

• Wir benennen erst einmal nur die Klassen und Methoden um.
• Die H2DB User müssen mit der letzten 3.x.x einen Diagnose-Backup-Export machen
• Für die neue Version erstellen wir eine Erst Datei mit umbenannten Tabellen
• Wird die neue Version gestartet, dann benennen wir die aktuelle DB um und erstellen ein leere DB mit dieser Erst Datei mit der aktuellen H2DB Version
• Die neue Version hat auch die umbenannten Tabellen im Code
• Dann importiert man mit dem Diagnose-Backup-Import die alten Daten

Ich denke nun, dass wir generell auch die anderen Umbenennungen nicht mehr in 3.0.0 machen sollten sondern erst in der 3.1.0, auch wenn das evtl. für Bugfixes bei 3.0.x dann nicht mehr so leicht ist diese zu mergen. Dann muss man sie halt doppelt fixen. Aber es wäre sicherlich besser die Änderungen in einigen Nightlys laufen zu lassen bevor wir sie offiziell rausgeben.

Wir bekommen die 3.0.0 sonst überhaupt nicht mehr fertig.

[lenilsas]

Ich denke auch die Umbenennungen in der DB sollten noch warten. Das vorgehen können wir ja später noch besprechen.

[mbmueller]

Prinzipiell finde ich die Umbenennung schon auch gut, ich bin da ja selber schonmal drüber gestolpert. Es würde aber auch eine gute Code-Dokumentation helfen, in der Klassen und deren Member beschrieben sind.