Feature #128
Von Julius Haman vor 9 Tagen aktualisiert
Die Soll-Version der Datenbank (`ModelVersion`) kommt heute aus der von Hand gepflegten Konstante `AssemblyConstants.DBVersion` und steht zusätzlich im Namen der EF-Migration (`Version3140`). Das ist redundant: Wer eine Migration anlegt, muss die Konstante mitziehen, und wer sie vergisst, bekommt eine Abweichung (der Kommentar in `MigrationService` warnt selbst davor). Außerdem ist die Namensgebung nicht durchgängig versionskodiert (z.B. `RemoveGearshifter`). ### Ziel Die Modellversion wird aus dem Namen der neuesten Migration abgeleitet. Die Konstante `DBVersion` entfällt, es gibt nur noch eine Quelle. ### Lösungsansatz * Migrationen heißen ab 3.1.4.0 `Version_a_b_c_d` (Klassennamen dürfen keine Punkte enthalten, die Unterstriche trennen die Segmente eindeutig, auch bei mehrstelligen Segmenten wie 3.1.10.0). Aufruf: `dotnet ef migrations add Version_3_1_5_0`. * `Version3140` ist noch unveröffentlicht und wird in `Version_3_1_4_0` umbenannt (Klasse, Dateien, Designer, Migrationsattribut, Testklasse `Version3140MigrationTests`). Bereits veröffentlichte Migrationen werden nicht angefasst: Ihre IDs stehen in der `__EFMigrationsHistory` der Nutzer-Datenbanken. * `EcContext.ModelVersion` liest die Version aus dem Namen der neuesten Migration (Reflection über die `Migration`-Typen des Model-Assemblys, kein Datenbankzugriff). * About-Fenster nutzt `ModelVersion` statt der Konstante. * Test, der sicherstellt, dass die neueste Migration dem Muster `Version_a_b_c_d` entspricht (sonst fällt ein falsch benannte Migration erst beim Start auf). ### Unverändert * Der Eintrag `Database|Version` in der Tabelle `Preferences` jeder Datenbank bleibt die Ist-Version der Datei. Er wird weiter gebraucht für die Legacy-Erkennung (2.2.3.53), den Schutz vor einer neueren Datenbank und die Anzeige. * Eine Migration pro Release bleibt die Konvention; innerhalb einer Version werden Änderungen in die Migration gefaltet. ### Hinweis Hinweise * Umbenennung der Migration: Entwicklungs-Datenbanken, die `Version3140` schon angewendet haben, brauchen einmalig `UPDATE __EFMigrationsHistory SET MigrationId = '20261002180240_Version_3_1_4_0' WHERE MigrationId = '20261002180240_Version3140';`, sonst hält EF die Migration für ausstehend und scheitert an der schon vorhandenen Spalte. * Zeitpunkt: erst nach einem Test mit echter Fahrt (#127) und eigener Commit, damit die Versionslogik beim Start nicht kurz vor dem Release von 3.1.4 geändert wird.