aidGer/issuetest — Issue #254: Migrationsskript: Spalten Stundenlohn und Handicap sollten nicht gelöscht werden
Author: Philly
Created: 2012-01-24 12:31:22+00:00
State: open
Labels: Fehler, Prio-Hoch

Ich habe jetzt diese ganzen manuellen Operationen zum Migrieren der *Daten* aus der alten DB ins Migrationsskript mit aufgenommen und ein aktualisiertes Skript beigefügt. (Bitte committen, mir fehlen dazu leider die Rechte) Nach dem Ausführen auf einer Kopie der Produktivdatenbank gelingt der aidGer-Start und die meisten Funktionen gehen auch soweit. An einigen Stellen (afaik nur bei 2 der Berichte) gibt es aber weiterhin Exceptions, die ich noch nicht genauer lokalisieren konnte.

Es gibt da derzeit noch ein Problem, und zwar sollten in @Hilfskraft@ die beiden Spalten @Stundenlohn@ und @Handicap@ nicht gedroppt werden, weil dadurch die bisherige OOo-Lösung aussteigen würde. Stattdessen sollten die Spalten als @Deprecated@ markiert/kommentiert werden.

Wenn ich die beiden DROPs aus dem Skript rausschmeisse, fliegen beim Start von aidGer diverse Exceptions. Ich vermute, AdoHive geht hier direkt über die Indizes der Spalten und liest Werte aus einer falschen Spalte, da die beiden o.g. Spalten noch existieren.

Eine Möglichkeit das zu fixen wäre die beiden Spalten neu anzulegen (somit hinten dranzuhängen) und die Werte zu kopieren (geht ganz einfach mit: UPDATE `table_name` SET `new_column` = `old_column`;). Sebastian: Könntest Du das bitte übernehmen? Weitere, ähnlich problematische DROPs würde ich noch (unter)suchen. Das mit dem Stundenlohn ist aber besonders kritisch, weil die Spalte in sehr vielen Abfragen der alten OOo-Lösung benutzt wird.

Zum parallelen Betrieb der alten + neuen Lösung müssten wir uns natürlich noch etwas überlegen. Ich schlage vor, den Stundenlohn periodisch via cron-job basierend auf der Qualifikation zu aktualisieren. Die jetzige OOo-Lösung kann ich im Moment nicht umschreiben, da die Berechnungen von aidGer noch nicht mit den Berechnungen der bisherigen Lösung verglichen werden konnten, und ich durch das Refactoring keine zusätzlichen Fehler einbauen will.
__Reporter:__ Daniel Kulesz
__Assigned to:__ Daniel Kulesz
__Begin:__ 2010-12-16
__End:__ 2011-01-19
__Completed:__ 100